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

Na tomto místˇe bude oficiální zadání vaší práce • Toto zadání je podepsané dˇekanem a vedoucím katedry, • musíte si ho vyzvednout na studiijním oddˇelení Katedry poˇcítaˇcu˚ na Karlovˇe námˇestí, • v jedné odevzdané práci bude originál tohoto zadání (originál zustává ˚ po obhajobˇe na katedˇre), • ve druhé bude na stejném místˇe neovˇerˇ ená kopie tohoto dokumentu (tato se vám vrátí po obhajobˇe).

i

ii

ˇ Ceské vysoké uˇcení technické v Praze Fakulta elektrotechnická Katedra poˇcítaˇcové grafiky a interakce

Bakaláˇrská práce

Informaˇcní systém pro restauraˇcní zaˇrízení Petr Vích

Vedoucí práce: Ing. Radek Malinský

Studijní program: Softwarové technologie a management, Bakaláˇrský Obor: Web a multimedia kvˇeten 2014

iv

v

Podˇekování Dˇekuji Ing. Radku Malinskému, vedoucímu bakaláˇrské práce, za cenné rady a podnˇety k rˇ ešené problematice. Dále bych chtˇel velmi podˇekovat své rodinˇe a pˇrátelum ˚ za morální podporu v prubˇ ˚ ehu studia i pˇri psaní bakaláˇrské práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatnˇe a použil jsem pouze podklady uvedené v pˇriloženém seznamu. Nemám závažný duvod ˚ proti užití tohoto školního díla ve smyslu §60 Zákona cˇ . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmˇenˇe nˇekterých zákonu˚ (autorský zákon).

V Praze dne 23. 5. 2014

...........................................................................

viii

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áˇrská práce se zabývá problematikou návrhu, implementace a následného nasazení informaˇcního systému pro restauraˇcní zaˇrízení do produkˇcní verze. Pˇri návrhu informaˇcního systému byl kladen hlavní duraz ˚ na provoz restaurace, pˇrípravu pokrmu˚ a nápoju, ˚ dále na sledování surovin potˇrebných pro jejich pˇrípravu. Návrh také zahrnuje funkce pro sledování objednávek a jejich stavu, ˚ pracovní výkaz zamˇestnancu˚ a monitoring cˇ inností, které v systému vykonali. V cˇ ásti popisující implementaci jsou shrnuty technologie, které byly k programování použity. Systém je navržen pomocí architektury Klient-Server.

ix

x

Obsah 1

Úvod

1

2

Popis problému, specifikace cíle 2.1 Cíle projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3

3

Analýza 3.1 Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Požadavky na informaˇcní systém . . . . . . . . . . . . . . . . . . . . 3.2.1 Funkˇcní požadavky . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Obecné požadavky . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Režim objednávek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Správa systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Správa skladu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Souˇcasná rˇ ešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Restaurace Chata Polanka . . . . . . . . . . . . . . . . . . . . 3.6.2 Restaurace U Báby Šubrový - Kokoˇrínský dul ˚ . . . . . . . . 3.6.3 Zámecká restaurace Nové Hrady . . . . . . . . . . . . . . . . 3.6.4 Restaurace v hotelu Erlebachova Bouda . . . . . . . . . . . . 3.6.5 Systémy nalezené rešeršním vyhledáváním . . . . . . . . . . 3.6.5.1 ABRA Software . . . . . . . . . . . . . . . . . . . . 3.6.5.2 Pokladní systém VIRTUOS pro restaurace a hotely 3.6.5.3 VECTRON . . . . . . . . . . . . . . . . . . . . . . . 3.6.6 Porovnání souˇcasných rˇ ešení . . . . . . . . . . . . . . . . . .

4

Návrh rˇešení 4.1 Výbˇer aplikaˇcního rozhraní . . . . . 4.1.1 Aplikaˇcní servery . . . . . . . 4.1.2 Aplikaˇcní frameworky . . . . 4.1.2.1 Hibernate . . . . . 4.1.2.2 Spring framework . 4.1.3 Databázové stroje . . . . . . . 4.1.4 Další použité technologie . . 4.1.5 Shrnutí použitých technologií 4.2 Diagramy aktivit . . . . . . . . . . . 4.2.1 Kontrola stavu zásob . . . . .

xi

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . . . . . . .

5 5 6 6 6 7 8 8 9 9 10 10 10 11 11 12 13 14

. . . . . . . . . .

15 15 15 16 17 18 19 20 20 21 21

xii

OBSAH

. . . . . . . . . . . . . . . .

22 22 22 23 23 23 24 25 25 26 26 26 27 27 27 28

5

Realizace 5.1 Model architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Návrh uživatelského rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Popis implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 29 29 33

6

Testování 6.1 Kategorie testu˚ . . . . . . . . . . . . . . . . . 6.1.1 Testování programátorem . . . . . . . 6.1.2 Usability test . . . . . . . . . . . . . . 6.1.2.1 Low fidelity prototype . . . 6.1.2.2 Testování hotového systému 6.2 Postup testování . . . . . . . . . . . . . . . . . 6.3 Výsledky testování . . . . . . . . . . . . . . .

35 35 35 35 35 38 38 40

4.3

4.4 4.5 4.6

4.7 4.8 4.9

7

4.2.2 Zaplacení útraty . . . . . . . . . . . . . . . 4.2.3 Doplnˇení zásob . . . . . . . . . . . . . . . . 4.2.4 Objednávka a dodávka pokrmu a nápoje . Model pˇrípadu˚ užití . . . . . . . . . . . . . . . . . 4.3.1 Správa systému . . . . . . . . . . . . . . . . 4.3.2 Objednávka a zhotovení pokrmu a nápoje Mapování požadavku˚ na model pˇrípadu˚ užití . . Doménový model . . . . . . . . . . . . . . . . . . . 4.5.1 Vztahy mezi entitami . . . . . . . . . . . . Stavové diagramy . . . . . . . . . . . . . . . . . . . 4.6.1 Položka na objednávce . . . . . . . . . . . . 4.6.2 Objednávka . . . . . . . . . . . . . . . . . . 4.6.3 Surovina . . . . . . . . . . . . . . . . . . . . Analytický model . . . . . . . . . . . . . . . . . . . Databázový model . . . . . . . . . . . . . . . . . . Model nasazení . . . . . . . . . . . . . . . . . . . .

Závˇer

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

41

A Seznam použitých zkratek

47

B Obsah pˇriloženého CD

49

C Návrh uživatelského prostˇredí

51

D UML diagramy

55

E Dotazník existujících rˇešení

61

F Low-fidelity prototype

63

Seznam obrázku˚ 3.1 3.2 3.3

Informaˇcní systém ABRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vituos - pokladní systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vectron - ukázky jednotlivých modulu˚ . . . . . . . . . . . . . . . . . . . . . .

11 12 13

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Hibernate - architektura aplikace . . . . . . . . . . . . . . . Pˇrehled funkcí Spring frameworku - architektura aplikace Diagram aktivit - Kontrola stavu zásob . . . . . . . . . . . . Diagram aktivit - Proces zaplacení útraty . . . . . . . . . . Diagram aktivit - Proces zaplacení útraty . . . . . . . . . . Diagram pˇrípadu˚ užití - Pˇríprava pokrmu a nápoje . . . . Stavový diagram - Položka objednávky . . . . . . . . . . . Stavový diagram - Surovina . . . . . . . . . . . . . . . . . . Diagram modelu nasazení . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

17 18 21 22 22 23 26 27 28

5.1 5.2 5.3 5.4 5.5

Základní layout informaˇcního systému . Zobrazení kategorie nápoju. ˚ . . . . . . . . Zobrazení seznamu položek v jídelníˇcku. Detail stolu v restauraci. . . . . . . . . . . Prostˇredí baru / kuchynˇe. . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

30 30 31 31 32

C.1 C.2 C.3 C.4 C.5

Návrh uživatelské rozhraní - seznam zamˇestnancu˚ . . . Návrh uživatelské rozhraní - detail pokrmu/nápoje . . Návrh uživatelské rozhraní - seznam stolu˚ v restauraci Návrh uživatelské rozhraní - seznam stolu˚ v restauraci Návrh uživatelské rozhraní - seznam stolu˚ v restauraci

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

51 51 52 52 53

D.1 D.2 D.3 D.4 D.5 D.6

Diagram aktivit - Objednávka a dodávka pokrmu a nápoje Stavový diagram - Objednávka od zákazníka . . . . . . . . Diagram pˇrípadu˚ užití - Správa systému . . . . . . . . . . . Domnévý model . . . . . . . . . . . . . . . . . . . . . . . . . Diagram Analytický model . . . . . . . . . . . . . . . . . . Diagram modelu architektury . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

55 55 56 57 58 59

xiii

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

xiv

˚ SEZNAM OBRÁZKU

Seznam tabulek 3.1

Porovnání existujících programu˚ . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.1

Mapování požadavku˚ na model pˇrípadu˚ užití . . . . . . . . . . . . . . . . .

24

6.1 6.2

Screener pro výbˇer uživatelu˚ k testování . . . . . . . . . . . . . . . . . . . . . Nálezy testování aplikace s uživateli. . . . . . . . . . . . . . . . . . . . . . . .

38 40

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Bakaláˇrská práce se zabývá analýzou a návrhem informaˇcního systému. První kapitolou je tento úvod. Ve druhé kapitole obnáší popis systému, seznam požadavku˚ na budoucí systém a upˇresnˇení obecných požadavku˚ pro následné nasazení. Tˇretí kapitola se zamˇerˇ uje na analýzu systému, podrobné rozepsání funkˇcních a obecných požadavku. ˚ Dále jsou v kapitole zmínˇena nˇekterá souˇcasná rˇ ešení podobných informaˇcních systému. ˚ V závˇeru kapitoly je srovnání výhod a nevýhod zmínˇených systému˚ a srovnání s navrženým systémem. V úvodu cˇ tvrté kapitoly jsou uvedeny aplikaˇcní servery, které se využívají jako bˇehové prostˇredí. Dále jsou v kapitole zmínˇeny aplikaˇcní frameworky, které v prvé rˇ adˇe usnadnují ˇ práci programátorum ˚ a zvyšují bezpeˇcnost celé aplikace. Podstatná cˇ ást kapitoly se zabývá znázornˇením požadavku˚ na systém pomocí diagramu˚ aktivit1 , diagramu˚ pˇrípadu˚ 2 užití a stavových diagramu˚ 3 . Zbylá cˇ ást kapitoly popisuje databázový, doménový a analytický model a model nasazení. V páté kapitole je podrobnˇe vysvˇetlen model architektury. Dále se kapitola zabývá návrhem uživatelského rozhraní. Následuje popis implementace stˇežejních cˇ ástí informaˇcního systému. Kapitola testování popisuje jednotlivé testy a jejich význam pro informaˇcní systém. Závˇer 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ˇrípadné rozšíˇrení souˇcasného návrhu rˇ ešení.

1

Diagram aktivit - Popis cˇ innosti, která se vykonává i bez informaˇcního systému (viz. 4.2). Diagram pˇrípadu˚ užití - Diagram popisuje cˇ innost, kterou vykonává systém (viz. 4.3). 3 Stavový diagram - Diagram popisuje jednotlivé stavy, kterých muže ˚ vybraná entita nabývat (viz. 4.6). 2

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle „Informaˇcní systém je soubor lidí, technologických prostˇredku˚ a metod, které zabezpeˇcují sbˇer, pˇrenos, zpracování a uchování dat za úˇcelem tvorby prezentace informací pro potˇreby uživatelu.“ ˚ [7] Informaˇcní systém patˇrí mezi cˇ asto používané pojmy v oboru informaˇcních technologií. Tímto pojmem je cˇ asto myšlen software, ale tento pojem zahrnuje mnohem širší odvˇetví než pouze informatiku. Úkolem informaˇcního systému je vykonávat pˇredem stanovené procesy a zpracovávat vstupní data. V dnešní dobˇe je nasazení informaˇcního systému nutnou, dalo by se rˇ íci až existenˇcní záležitostí. Kvalitní systém pomáhá s organizací kontaktu˚ na klienty (zákazníky), s požadavky od zákazníku˚ (objednávek), i s plánováním budoucích obchodních aktivit. Díky informaˇcnímu systému je možné naplánovat obchodní strategii s ohledem na pˇredchozí provoz.

2.1

Cíle projektu

Cílem projektu je navrhnout a implementovat informaˇcní systém pro rˇ ízení a správu chodu restauraˇcního zaˇrízení. Osobní cíle: • Nauˇcit se základy jazyka Java EE. • Proniknout do logiky životního cyklu algoritmu. ˚ • Prozkoumat existující frameworky1 používané pˇri programování webových aplikací.

1

Framework - pomocná struktura pˇri programování aplikací.

3

4

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

Kapitola 3

Analýza Analytická cˇ ást návrhu informaˇcního systému klade duraz ˚ na funkˇcní a obecné požadavky celého informaˇcního systému. Hlavním úkolem je usnadnit rˇ ízení provozu restauraˇcního zaˇrízení (kontrola stavu zásob, objednávka nových surovin, rˇ ízení stavu objednávek, atd.). Závˇerem jsou zmínˇena existující rˇ ešení podobných informaˇcních systému. ˚

3.1

Uživatelské role

Uživatelské role mají v informaˇcním systému stˇežejní úlohu. Díky uživatelským rolím je možné rozdˇelit informaˇcní sytém do jednotlivých logických celku˚ a také specifikovat jednotlivé úkoly jednotlivých uživatelu. ˚ • Vedoucí - Uživatel Vedoucí má na starosti chod restaurace. Dále má na starosti zamˇestnance, tvorbu a editaci jídelníˇcku, sledování objednávek materiálu, ale i objednávek od zákazníku. ˚ • Kuchaˇr - Uživatele Kuchaˇr zajímají pouze objednávky pokrmu˚ a jejich zhotovení. • Barman - Uživatele Barman zajímají pouze objednávky nápoju˚ a jejich zhotovení. ˇ ˇ • Cíšník - Uživatel Cíšník má na starosti zákazníky. Vytváˇrí nové objednávky a donáší pokrmy z kuchynˇe ke stolu. Dále má na starosti dokonˇcení objednávek (placení, stornování). • Skladník - Uživatel Skladník vytváˇrí nové objednávky (pˇrípadnˇe kontroluje a edituje objednávky, které se vytvoˇrily samy automatickou kontrolou). Kontroluje stav objednávek a pˇri doruˇcení objednávky zboží zásilku pˇrijme. Potvrzením zásilky v systému se suroviny automaticky pˇripíší na sklad.

5

6

KAPITOLA 3. ANALÝZA

3.2

Požadavky na informaˇcní systém

Pˇredmˇetem této kapitoly je popis funkˇcních a obecných požadavku˚ na informaˇcní systém. Mezi funkˇcní požadavky se rˇ adí požadavky od uživatelu. ˚ Mezi obecné požadavky patˇrí požadavky na použité technologie (operaˇcní systém, databáze) a další obecné požadavky, které pˇrímo nesouvisí s logikou systému.

3.2.1

Funkˇcní požadavky

• Systém bude umožnovat ˇ vytváˇrení objednávek zboží. U každé objednávky bude seznam objednaných surovin. Po doruˇcení objednávky se suroviny automaticky pˇridají na sklad. • Systém bude umožnovat ˇ vytváˇrení nových pokrmu˚ a nápoju˚ a jejich kategorií. Každá položka (pokrm, nápoj) muže ˚ patˇrit do libovolného poˇctu kategorii. • Systém bude umožnovat ˇ vytvoˇrení objednávek pokrmu˚ a nápoju. ˚ Objednávky pokrmu˚ budou automaticky odeslané ke zpracování do kuchynˇe a objednávky nápoju˚ na bar. • Systém bude umožnovat ˇ vytvoˇrení nového zamˇestnance, editacei osobních údaju˚ a také smazaní zamˇestnance ze systému. Každý zamˇestnanec bude mít alesponˇ jednu adresu, telefon a e-mail. • Systém bude umožnovat ˇ sledování pracovních výkazu˚ jednotlivých zamˇestnancu. ˚ • Systém bude umožnovat ˇ zápis zamˇestnance na smˇenu. • Systém bude umožnovat ˇ sledování jednotlivých objednávek. Dále bude kontrolovat, jaké objednávky vytvoˇril který zamˇestnanec. • Systém bude mít automatickou kontrolu stavu surovin. Pˇri objednání položky se provede kontrola, zda je ve skladu dostatek surovin pro vytvoˇrení další objednávky. V pˇrípadˇe, že nebude dostatek suroviny, zablokují se všechny položky, které potˇrebují danou surovinu pro pˇrípravu. Dále se automaticky vytvoˇrí objednávka surovin. Surovina, která na skladu došla, bude pˇridána se seznam objednávky.

3.2.2

Obecné požadavky

• Informaˇcní systém bude využívat PostgreSQL databázi. • Informaˇcní systém bude aplikace typu Klient-Server1 . • Server bude plnit roli webového serveru a aplikaˇcního serveru. Na serveru bude nainstalovaný Apache Tomcat. • Informaˇcní systém bude mít pˇrehledné a uživatelsky pˇrívˇetivé grafické prostˇredí. 1

Klient-Server - Jedná se o typ softwarové architektury. Klient odešle požadavek, vˇetšinou prostˇrednictvím webového prohlížeˇce. Následnˇe server požadavek vyhodnotí a odešle odpovˇed’ zpˇet klientovi.

3.3. REŽIM OBJEDNÁVEK

3.3

7

Režim objednávek

ˇ Cíšník u daného stolu vytvoˇrí objednávku pokrmu, ˚ která se odešle do kuchynˇe, a nápoju, ˚ ˇ kterou vybaví Cíšník u baru. ˇ Objednané pokrmy a nápoje se v informaˇcním systému evidují. Kuchaˇr, nebo Cíšník u baru, si zobrazuje položky a mˇení jejich stav. Každá položka objednávky bude mít právˇe jeden z uvedených stavu: ˚ • Vybrané - položka je zvolena na objednávkový lístek, ale zatím není odeslána. • Objednané - položka je závaznˇe objednaná a odeslaná do kuchynˇe/na bar. • V pˇrípravˇe - zamˇestnanci zaˇcali pracovat na pˇrípravˇe pokrmu/nápoje. • Pˇripravené - položka je pˇripravená k doruˇcení zákazníkovi. • Doruˇcené - objednávka položky byla doruˇcená zákazníkovi. • Odmítnuté - zákazník odmítl pˇrijmout pokrm/nápoj. • Zaplacené - zákazník položku zaplatil. ˇ Jakmile si zákazník pˇreje zaplatit útratu, uvˇedomí Cíšníka, který uzavˇre objednávku. ˇ Zákazník zvolí zpusob ˚ platby (kartou, hotovˇe, stravenkou) a zaplatí Cíšníkovi útratu. Objednávka bude nabývat jednoho z následujících stavu˚ • Nezaplaceno - Neuzavˇrená objednávka. Zákazník si muže ˚ pˇriobjednat položku z jídelního lístku. • Zaplaceno - Objednávka je uzavˇrená a zaplacená. Zákazník už nemuže ˚ na objednávku pˇridat další položku. • Stornováno - Objednávka je uzavˇrená, ale není zaplacená. Tento stav se použije v pˇrípadˇe, že zákazník odešel bez placení, nebo odmítl z nˇejakého duvodu ˚ objednávku zaplatit. Jednotlivé položky jídelního lístku nabývají dvou stavu: ˚ • Povoleno - ve skladu je dostatek surovin pro objednání alesponˇ jedné položky. • Zakázáno - ve skladu není dostatek surovin pro objednání položky. Pˇri zmˇenˇe stavu položky s "Povoleno"na "Zakázáno"je automaticky vytvoˇrena objednávka surovin.

8


3.4

Správa systému

Informaˇcní systém eviduje veškeré zamˇestnance. Mezi hlavní funkce patˇrí pˇridání, odebrání, editace a zobrazení všech zamˇestnancu. ˚ U každého zamˇestnance jsou osobní informace (jméno, pˇríjmení, adresa, telefon, email, telefon, atd.) a pracovní informace (plat a uživatelská role v informaˇcním systému). Systém umožnuje ˇ sledovat pracovní výkaz všech zamˇestnancu. ˚ Když pˇrijde zamˇestnanec do práce, pˇrihlásí se do systému. Informaˇcní systém umožnuje ˇ spravovat suroviny používané pro pˇrípravu pokrmu. ˚ Hlavní funkce jsou pˇridání, odebrání, editace a zobrazení surovin a jednotek (hmotnost, objem, poˇcet). Surovina má název, množství, jednotku. Pomocí informaˇcního systému je možné spravovat jídelníˇcek, jeho kategorie (polední menu, akˇcní nabídka, smažená jídla, pˇrílohy, atd.) a také samotné pokrmy (smažený sýr, hranolky, gulášová polévka, zmrzlinový pohár, atd.). Hlavní funkce jsou pˇridání, odebrání, editace a zobrazení položek a kategorií. Kategorie má jen svuj ˚ název. Do každé kategorie mohou být pˇridávány položky. Položka má název, cenu, seznam surovin surovin a postup zhotovení položky vˇcetnˇe normování na jednu porci.

3.5

Správa skladu

Uživatel Skladník muže ˚ pˇridávat, odebírat, editovat a zobrazovat objednávky na suroviny. Každá objednávka obsahuje datum a seznam surovin, které jsou objednané, vˇcetnˇe jejich množství. Uživatel Skladník muže ˚ pomocí informaˇcního systému mˇenit stav objednávky surovin. Každá objednávka surovin bude mít jeden z následujících stavu: ˚ • Vytvoˇrené automaticky - objednávka byla vytvoˇrena pˇri kontrole stavu surovin. • Vytvoˇreno - Objednávku vytvoˇril Skladník, pˇrípadnˇe editoval objednávku, která byla automaticky vytvoˇrená. • Objednáno - Skladník oznaˇcil objednávku jako odeslanou dodavateli. • Doruˇceno Dodavatel doruˇcil suroviny. Suroviny se automaticky pˇripoˇcítali na sklad. • Nedoruˇceno - Dodavatel suroviny nedoruˇcil.

ˇ ˇ 3.6. SOUCASNÁ REŠENÍ

3.6

9

Souˇcasná rˇešení

Na trhu s informaˇcními systémy je nˇekolik podobných systému, ˚ které je možné porovnat s návrhem, který je pˇredmˇetem této práce. Pˇri vymýšlení informaˇcního systému jsem navštívil nˇekolik restaurací, které používají pokladní nebo restauraˇcní systém. Na základˇe pˇredem vytvoˇreného dotazníku jsem se snažil zjistit, jaké funkce používaný systém podporuje, pˇrípadnˇe jak jsou s ním zamˇestnanci spokojeni. V poslední rˇ ade jsem se ptal na poˇrizovací náklady na zakoupení, pˇrípadnˇe pronájem systému. Pˇred výbˇerem systému pro zaˇrízení je v prvé rˇ adˇe nutné specifikovat typ restauraˇcního zaˇrízení. Funkce, které jsou zásadní pro spolehlivé fungování restaurace, se budou lišit napˇríklad pro fastfood, pivnici a nebo pro restauraci. Informaˇcní systém restaurace typu „fastfood“ nemusí obsahovat seznam stolu˚ v restauraci. Pro tento typ zaˇrízení je dostaˇcující, aby se objednávka hned zaplatila. V restauraˇcním zaˇrízení typu „pivnice“ by bylo výhodnˇejší, aby úˇcet nebyl vázaný na konkrétní stul, ˚ ale pˇrímo na zákazníka. A naopak v restauraci bˇežného typu je výhodné, když je objednávka k danému stolu. Další podstatný rozdíl je v sortimentu pˇripravovaných pokrmu. ˚ Pokud se restaurace 2 specializuje pouze na „minutky“ staˇcí, aby byl jeden centrální sklad. Naopak pokud se nabídce objevují i pˇredem pˇripravené pokrmy, bylo by vhodné, aby sklad surovin mohl obsahovat i hotové pokrmy.

3.6.1

Restaurace Chata Polanka

Tato restaurace používá pokladní systém GASTON. Systém dokáže pracovat ve dvou ruz˚ ných režimech. Režim pro vedoucího podporuje funkce pro vytváˇrení pokrmu˚ a nápoju, ˚ rozmístˇení stolu˚ v restauraci a správu skladu surovin. Režim pro cˇ íšníka podporuje vytváˇrení objednávek. Mezi další funkce, které systém nabízí, patˇrí tisk objednávek pokrmu˚ v kuchyni, provedení inventury za urˇcité období. Výhody systému • Pˇrihlášení zamˇestnance pomocí cˇ ipové karty. Nevýhody systému • Suroviny, které se použijí pro pˇrípravu pokrmu, ˚ se musí ruˇcnˇe odepsat ze skladu není zpˇetná vazba z kuchynˇe. • Nepˇrehledná mobilní verze systému - informaˇcní systém má i svoji mobilní verzi, kterou jsem nevidˇel, ale v restauraci mi rˇ ekli, že pro svuj ˚ nepˇrehledný 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ˇrizovací náklady na systém se pohybují v rˇ ádu 80 - 100 tisíc korun. Zakoupení programu je jednorázové, nemá tedy cˇ asovˇe omezenou licenci. 2

Minutka - pokrm, který se pˇripravuje až po objednávce zákazníka.

10


3.6.2

Restaurace U Báby Šubrový - Kokoˇrínský dul ˚

V této restauraci informaˇcní systém zatím nepoužívají, ale majitel restaurace mˇel ucelenou pˇredstavu, jaké funkce by mˇel systém obsahovat. S majitelem restaurace jsem v kontaktu. Bˇehem letních prázdnin je v plánu informaˇcní systém, který je pˇredmˇetem této práce, nasadit do ostrého provozu. Funkce, které by mˇel systém obsahovat: • objednávka pokrmu, ˚ • objednávka nápoju, ˚ • objednávka surovin, • správa a tvorba jídelního lístku, • provoz kuchynˇe a baru (puvodnˇ ˚ e chtˇel majitel do kuchynˇe a na bar pouze tisk lístku. ˚ Po spoleˇcné diskuzi jsme našli rˇ ešení jak vytvoˇrit uživatelské prostˇredí tak, aby bylo jak použitelné v praxi, tak užiteˇcné z pohledu systému), • sklad surovin, • kontrola zásob pˇri objednávce pokrmu˚ a nápoju. ˚

3.6.3

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 pokrmu˚ a nápoju. ˚ Objednávky pokrmu˚ dokáže automaticky odeslat na tiskárnu do kuchynˇe. K systému se dají dokoupit další moduly, které restaurace zakoupené nemˇela.

3.6.4

Restaurace v hotelu Erlebachova Bouda

Hotelový a restauraˇcní systém, který zde používají se jmenuje „DeCe“. Jedná se o komplexní informaˇcní systém, který nabízí následující funkce: • Objednávka pokrmu˚ • Objednávka nápoju˚ • Správa skladu surovin • Inventura • Systém podporuje pouze tisk lístku˚ v kuchyni a na baru • Pˇrehled tržeb Obsluha restaurace si systém velmi pochvalovala. Na první pohled se systém zdál pˇrehledný a intuitivní. I pˇres všechny kladné a pozitivní ohlasy bude systém nahrazen modernˇejším, který je programovaný pˇrímo na zakázku hotelu.


3.6.5

11

Systémy nalezené rešeršním vyhledáváním

S informaˇcními systémy v následující podkapitole nemám žádnou praktickou zkušenost. Pro rozšíˇrení znalostí o fungování podobných informaˇcních systému˚ jsem se inspiroval u výrobcu˚ systému. 3.6.5.1

ABRA Software

Spoleˇcnost ABRA Software a. s.3 vyvíjí a prodává, pˇrípadnˇe pronajímá licenci na komplexní informaˇcní systém nejen pro restauraˇcní zaˇrízení. Informaˇcní systém je rozdˇelen do nˇekolika modulu, ˚ které by se daly shrnout do následujících kategorií. ˇ • Rízení firmy - docházka, reporty4 , personalistika5 . ˇ • Rízení výroby - výroba, gastro-výroba, kapacitní plánování. • Vztahy se zákazníky - adresáˇr, pošta, emaily a interní vzkazy. ˇ • Rízení skladu - skladové hospodáˇrství, cˇ árové kódy. • Správa financí - mzdy, danová ˇ evidence, pokladna. • Nákup a prodej - nákup, prodej, e-shop.

Obrázek 3.1: Informaˇcní systém ABRA[38]

3

ABRA a. s. - Webové stránky spoleˇcnosti jsou www.abra.eu. Report - výstupy záznamu˚ z informaˇcního systému. 5 Personalistika - komponenta pro správu zamˇestnancu. ˚ 4

12


3.6.5.2

Pokladní systém VIRTUOS pro restaurace a hotely

Virtuos6 je komplexní informaˇcní systém pro restauraˇcní zaˇrízení a hotely. Informaˇcní systém obsahuje tyto cˇ ásti: • Pokladna - Tento modul obsahuje celou rˇ adu funkcionalit, napˇr. mobilní cˇ íšník, vˇernostní systém zákazníku, ˚ modul pro pizzerii, rezervaci stolu. ˚ Celou aplikaci je možné pohodlnˇe ovládat dotykem, pokud jsou splnˇené hardwarové požadavky. Dále modul nabízí tisk úˇctenek, odpis surovin ze skladu. Všechny výstupy je možné zobrazit pomocí grafu. ˚ • Sklad potravin Mezi funkce modulu Sklad potravin patˇrí rˇ ízení provozu více skladu, ˚ 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ˇrímo provázaný s funkcemi modulu Kuchynˇ a Pokladna • Kuchynˇ - Souˇcástí modulu Kuchynˇ je seznam receptu˚ (modul obsahuje seznam základní receptur pro pˇrípravu pokrmu˚ a nápoju, ˚ dále obsahuje knihovnu s pˇribližnˇe tisícem bˇežnˇe používaných receptu), ˚ odpis surovin ze skladu, kalkulace jednotlivých pokrmu, ˚ rautu, ˚ spotˇrebu surovin pro jednotlivé pokrmy a také spotˇrební koš. Všechny moduly uchovají informace o všech duležitých ˚ zmˇenách a operacích.

Obrázek 3.2: Vituos - pokladní systém[39]

6

informaˇcní systém spoleˇcnosti „TPC spol. s r.o.“ - Webové stránky spoleˇcnosti jsou http://www.tpc.cz/


3.6.5.3

13

VECTRON

Spoleˇcnost VECTRON vytváˇrí pokladní a hotelový systém, ale také poskytuje hardwarovou podporu. Informaˇcní systém se stejným názvem jako je název firmy se skládá z nˇekolika na sobˇe nezávislých modulu. ˚ • Skladový program Skladový program je urˇcený pro správu skladu, vytváˇrení sestav a odpisu˚ jednotlivých surovin ze skladu. Mezi další funkce modulu patˇrí zobrazení a tisk stavu zásob, hlavního i pˇridružených (kuchyn, ˇ bar) skladu. ˚ Dále modul podporuje provádˇení inventury (celkového skladu i pˇridružených skladu), ˚ flexibilní pˇrepínání sazby DPH a také umožnuje ˇ vést pokladní deník. • Hotelový program Tento modul poskytuje komplexní rˇ ešení pro hotelovou cˇ ást, hlavnˇe hotelovou recepci a pˇrípadné pokladny, které mohou být umístˇeny kdekoli v lokální poˇcítaˇcové síti. Mezi další funkce patˇrí ubytování hostu, ˚ vytváˇrení statistik vytížení hotelu. Ke každému pokoji je možné zobrazit podrobnosti o kapacitˇe, volných místech a pˇrípadnˇe informace o uživatelském úˇctu ubytovaných osob. Systém také umožnuje ˇ sledování telefonních hovoru. ˚ • Vectron Commander 7 Jedná se o centrální komunikaˇcní prostˇredek, 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 modulu˚ z jednoho místa. Pomocí modulu Vectron Commander 7 je možné snadno dotvoˇrit uživatelské rozhraní (povolovat, nebo zakazovat jednotlivé funkce).

Obrázek 3.3: Vectron - ukázky jednotlivých modulu[40], ˚ [41], [42], [43]

• POS Touch patˇrí mezi jeden z prvku˚ hardwarové podpory spoleˇcnosti. Jedná se o multifunkˇcní dotykovou obrazovku se zabudovaným pokladním systémem. Dále zaˇrízení obsahuje malý display otoˇcený k zákazníkovi.

14

3.6.6


Porovnání souˇcasných rˇešení

V tabulce 3.1 jsou shrnuty výhody a nevýhody vybraných systému˚ (spoleˇcnˇe s navrhovaným systémem). Na trhu s informaˇcními systémy je možné koupit kvalitní informaˇcní systém. Systémy se vˇetšinou skládají z jednotlivých a samostatných modulu. ˚ Je tedy možné systém lépe upravit na míru. Nevýhodou takovýchto systému je bezesporu poˇrizovací cena. Jedním z požadavku, ˚ které jsou kladeny na navrhovaný informaˇcní systém, je použití open-source technologií. Pˇri použití open-source technologií se výraznˇe snižují i celkové náklady na systém, protože se nemusí platit licenˇcní poplatky za používání komerˇcních systému. ˚

Shrnutí

Název

Výhody

Nevýhody

GASTON

jednoduché rˇ ešení, rozmístˇení stolu˚ v restauraci

SEPTIM

snadná obsluha

DeCe

rˇ ešení pro restauraci i hotel

ABRA

klient-server, více databází, jazykové mutace, možný pronájem licence rozdˇelený na moduly, v kuchyni velký poˇcet receptu˚ rozdˇelený na moduly, možnost hlavního a pˇridružených skladu˚ klient-server, postaveno na opensource technologiích, minimální požadavky na klientský poˇcítaˇc, více typu˚ databází

nevzhledný design, ruˇcní odpocˇ et surovin ze skladu, obtížnˇe použitelný mobilní cˇ íšník pouze pokladna, tisk lístku˚ v kuchyni velmi chybový mobilní cˇ íšník, zastaralé rˇ ešení a bez aktualizací vysoká cena, velmi vysoké hardwarové nároky

Virtuos Vectron RIS - navrhované rˇ ešení

pouze MS Windows pouze MS Windows pouze cˇ eština, jeden centrální sklad

Tabulka 3.1: Porovnání existujících programu˚

Kapitola 4

Návrh rˇešení V této kapitole jsou popsány používané technologie pro programování webových a podnikových aplikací. První cˇ ást kapitoly je vˇenována aplikaˇcním serverum. ˚ Další cˇ ásti jsou vˇenovány práci s databází, možnostem pˇripojení k databázi a frameworkum ˚ pro vývoj aplikací. V závˇeru této kapitoly jsou popsány ruzné ˚ typy databází, které je možné použít pˇri vytváˇrení aplikací pomocí technologie Java EE.

4.1

Výbˇer aplikaˇcního rozhraní

Pro tvorbu webových a podnikových aplikací v Java EE existuje veliký poˇcet technologií. V první cˇ ásti této kapitoly budou zmínˇeny nejpoužívanˇejší technologie.

4.1.1

Aplikaˇcní servery

Aplikaˇcní server je software, který zprostˇredkovává bˇeh komponent distribuovaných aplikací. Také muže ˚ obsluhovat nˇekolik ruznˇ ˚ e nakonfigurovaných kontejneru˚ pro komponen1 ty . Mezi nejˇcastˇeji používané komponenty patˇrí webový, souborový, databázový, autorizaˇcní server, atd. Aplikaˇcní server není totéž jako webový server. Aplikaˇcní server plní daleko rozsáhlejší funkci a web server je pouze jedna komponenta z mnoha. Drtivá vˇetšina aplikaˇcních serveru˚ vychází z podpory standardu Java Platform Enterprise Edition (Java EE). Díky podpoˇre Java EE je možné využívat další vlastnosti (EJB2 , JMS3 , XML 4 , SOAP5 , atd.). Aplikaˇcní server muže ˚ mimo jiné plnit i roli managed serveru. Managed server je vzdálený poˇcítaˇc, 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árovenˇ 1

Komponenta - samostatnˇe fungující cˇ ást aplikaˇcního serveru EJB (Enterprice Java Bean) - Komponenta rˇ ízená serverem pro modulární vytváˇrení aplikací. 3 JMS (Java Message Service) - Služba umožnují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ˇrizuje výmˇenu dat mezi dvˇema aplikacemi. 2

15

ˇ KAPITOLA 4. NÁVRH REŠENÍ

16

je zákazník potˇrebuje používat i mimo firemní kanceláˇr). Hlavní výhoda managed serveru˚ spoˇcívá v pˇrenesení odpovˇednosti za správu hardwaru a zálohování na externí firmu, která se na tuto problematiku pˇrímo specializuje. • Apache Tomcat - open source6 aplikaˇcní 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ˇcních serveru˚ pro prostˇredí Java EE, které zaˇcala vyvíjet firma Sun Microsystems (dnes Oracle).

4.1.2

Aplikaˇcní frameworky

Aplikaˇcní framework je softwarová knihovna, která pomáhá programátorum ˚ pˇri vývoji nové aplikace. Vˇetšina frameworku˚ obsahuje kostru pro vytvoˇrení aplikace, která obsahuje základní zabezpeˇcení a velmi urychlí první cˇ ást vývoje aplikace. Hlavními duvody, ˚ proˇc aplikaˇcní frameworky vznikly, bylo jednak ušetˇrit opakující se práci programátorum, ˚ dále snížit celkové náklady na vznik nové aplikace a v neposlední rˇ adˇe vytváˇret bezpeˇcnˇejší aplikace. Existuje rˇ ada specializovaných frameworku˚ tzv. CMS7 Aplikaˇcní frameworky se nepoužívají jen pro tvorbu grafického rozhraní (GUI8 ), ale také pro tvorbu bussinnes logiky celé aplikace. Mezi hlavní výhody aplikaˇcních frameworku˚ patˇrí: • Snadnˇejší udržitelnost a úprava zdrojového kódu aplikace. • Propracovaný objektový návrh. • Vysoká úrovenˇ zabezpeˇcení. • Snížení nákladu˚ na celkovou cenu aplikace.

6

Open source - licence pro volnˇe šiˇritelný software. CMS (content managment system) - Tyto systémy se cˇ asto používají pˇri vytváˇrení webových stránek nebo e-shopu. ˚ Uživatel pouze zvolí šablonu a doplní obsah aplikace. 8 GUI (graphical user interface) - uživatelské rozhraní výsledné aplikce 7

ˇ ˇ APLIKACNÍHO 4.1. VÝBER ROZHRANÍ

4.1.2.1

17

Hibernate

Hibernate je vysoce výkonný, objektovˇe orientovaný framework, který zprostˇredkovává komunikaci s databází. Vytváˇrí persistentní spojení s databází a díky propracovaným dotazum ˚ minimalizuje poˇcet pˇrístupu˚ k databázi. V aplikaˇcní logice se hibernate nachází mezi POJO9 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ˇrebuje aplikaˇcní server. • Umožnuje ˇ zmˇenu databáze bez jediné zmˇeny 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ˇrídu, která má nadefinované parametry a dále jen getry a setry


18

4.1.2.2

Spring framework

Spring framework je jeden z nejˇcastˇeji používaných aplikaˇcních frameworku˚ pˇri vytvárˇ ení enterprise aplikací v jazyku Java EE. Díky tomuto frameworku jsou vývojáˇri schopni vytváˇret vysoce výkonné aplikace, které jsou zárovenˇ snadno testovatelné a jejich kód je znovu použitelný. Spring framework je rozdˇelený do jednotlivých a na sobˇe nezávislých modulu, ˚ které je možné použít. Záleží pouze na programátorovi, jaké moduly použije. Spring framework obsahuje okolo 20 modulu, ˚ které je možné pˇri programování používat, diagram jednotlivých modulu˚ je zobrazen na obrázku 4.2.

Obrázek 4.2: Pˇrehled funkcí Spring frameworku - architektura aplikace[10] Ve zbytku této podkapitoly jsou podrobnˇeji pˇredstaveny nˇekteré moduly, které je možné použít. Core Container ˇ Tento modul obsahuje cˇ ásti Core, Beans, Context a Expression Language. Cást „BeanFac10 tory“ je programována podle návrhového vzoru „Factory “. Expression language, jak prozrazuje název, je skriptovací jazyk pro generování html obsahu. Web Nejvíce používaným modulem z této cˇ ásti je modul Web-servlet, který poskytuje implementaci MVC. Spring MVC framework umožnuje ˇ cˇ istˇe oddˇelit aplikaˇcní logiku od zbytku aplikace. 10

Factory - návrhový vzor, který se stará o vytvoˇrení nové instance objektu dané tˇrídy v momentˇe, kdy je potˇreba.

ˇ ˇ APLIKACNÍHO 4.1. VÝBER ROZHRANÍ

4.1.3

19

Databázové stroje

V souˇcasné dobˇe jsou databáze nejˇcastˇejším datovým úložištˇem používaným pro ukládání dat webových stránek. Existuje velké množství databázových stroju, ˚ které mohou být nainstalovány na server. • MySQL - multiplatformní databáze, která je využívána u vˇetšiny webových aplikací. Komunikace s databází probíhá pomocí jazyka SQL, který se používá u vˇetšiny databází. MySQL má, stejnˇe jako ostatní databáze, rozšíˇrení 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ˇežnˇeji se používá ve spojení v kombinaci tzv. LAMP (Linux, Apache, PHP, MySQL). MySQL databáze byla od zaˇcátku optimalizována hlavnˇe pro rychlost i za cenu zjednodušení nˇekterý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ˇcastˇeji používá aplikace phpMyAdmin. • PostgreSQL - objektovˇe-relaˇcní databázový systém vydaný pod licencí MIT (jedná se o open source licenci). PostgreSQL je primárnˇe vyvíjen pro UNIXové systémy, ale exitují také instalaˇcní balíˇcky pro ostatní operaˇcní systémy. Stejnˇe 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 rˇ á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ˇcní databázový systém vyvíjený pod licencí public domain11 . Celý databázový systém je obsažený v relativnˇe malé knihovnˇe psané v jazyce C. Databázový server je spuštˇen jako samostatný proces a nejedná se, na rozdíl od vˇetšiny bˇežných databázových serveru, ˚ tedy o aplikaci typu Klient-Server. SQLite je pouze malá knihovna, která se pˇrilinkuje pˇrí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ˇrípona DBM). V SQLite je implementován bˇežný standart SQL jazyka (opˇet 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ávum. ˚


20

4.1.4

Další použité technologie

V teto cˇ ásti kapitoly jsou uvedeny zbývající aplikace, které byly použity pˇri vytváˇrení 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ˇrevážnˇe pro verzování jednotlivých cˇ ásti kódu. Hlavní pˇrínos používání se projeví pˇri programování jedné aplikace týmem programátoru. ˚ Další hojnˇe používanou funkcí je vytváˇrení jednotlivých vývojových vˇetví, které je možné sluˇcovat opˇet do jedné. Maven Maven je nástroj, který automaticky stahuje knihovny, které jsou pˇri programování aplikace potˇrebné. 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ˇredá rˇ ízení automatické obsluze. To samé platí pˇri hlídání aktualizací knihoven. Apache Tiles Apache Tiles je šablonovací framework používaný pro vytváˇrení jednotného vzhledu aplikace, dále se dá použít pro tvorbu uživatelského menu a všeobecnˇe pro vykreslení spoleˇcných cˇ ástí webové stránky (hlaviˇcka, patiˇcka, menu, atd.) Boostrap Bootstrap obsahuje jak knihovny css, tak javascript. Hlavní použití je pˇri tvorbˇe jednotlivých cˇ ástí uživatelského rozhraní (modální formuláˇre, validace formuláˇru˚ pomocí javascriptu, zobrazení informaˇcní hlášek, atd.).

4.1.5

Shrnutí použitých technologií

Pro potˇreby tohoto projektu byly zvoleny technologie Tomcat, Hibernate, Spring framework a databáze PostgreSQL. Pro tvorbu uživatelského rozhraní byly zvoleny bˇežnˇe používané technologie na tvorbu webových stránek (css a java script - pˇresnˇeji knihovny bootstrap) Tyto technologie byly vybrány pro svoje jednoduché, snadné používání a zárovenˇ velmi efektivní výsledky. Pro tvorbu jednotného layoutu celé aplikace byla zvolena knihovna Apache Tiles. Dále byly, hlavnˇe bˇehem 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í podpurných ˚ knihoven). Aplikace byla programována ve vývojovém prostˇredí Netbeans.

4.2. DIAGRAMY AKTIVIT

4.2

21

Diagramy aktivit

Diagram aktivit je jeden z mnoha typu˚ UML12 diagramu, ˚ který se používá pro modelování procedurální logiky, procesu˚ a zachycení workflow13 . Pˇri návrhu softwaru se diagramy aktivit používají pro schématické zachycení souˇcasných aktivit, které se vykonávají i bez informaˇcního systému.

4.2.1

Kontrola stavu zásob

Aktivita zaˇcíná v okamžiku vytvoˇrení nové objednávky pokrmu nebo nápoje zákazníkem. V prvé rˇ adˇe se musí provést normování surovin podle objednávky. Kuchaˇr si odebere suroviny, které bude potˇrebovat na uvaˇrení všech pokrmu˚ a pˇrípravu nápoju. ˚ V dalším kroku se musí ovˇerˇ it, zda je dostatek surovin i pro pˇrípravu dalších položek.

Obrázek 4.3: Diagram aktivit - Kontrola stavu zásob

V pˇrípadˇe, že stav suroviny klesne pod hranici, ze které je možné uvaˇrit další porci, musí se v jídelníˇcku zakázat všechny položky, které potˇrebují danou surovinu. Spoleˇcnˇe se zablokováním pokrmu nebo nápoje by se mˇela vytvoˇrit 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ˇrípravu dostatek.

12 UML (Unifite modeling language) - Jedná se o znaˇckovací jazyk, který se používá pro modelování diagramu˚ pˇri návrhu softwaru. 13 Workflow - pracovní postup, postup pˇri vykonávání cˇ innosti.


22

4.2.2

Zaplacení útraty

Diagram popisuje proces placení objednávky. Aktivita zaˇcíná žádostí o platbu. Zákazník si vybere hotovostní, nebo bezhotovostní zpusob ˚ platby. V okamžiku dokonˇcení platby je vytištˇena úˇctenka.

Obrázek 4.4: Diagram aktivit - Proces zaplacení útraty

4.2.3

Doplnˇení zásob

Diagram popisuje proces objednání a naskladnˇení surovin. Aktivita zaˇcíná komunikací s dodavatelem zboží. V pˇrípadˇe, ž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ˇehne závazná objednávka, potvrzení objednaného zboží ze strany dodavatele a dodání surovin. Po dodání surovin Skladník pˇrekontroluje zboží a následnˇe suroviny pˇrebere a naskladní.

Obrázek 4.5: Diagram aktivit - Proces zaplacení útraty

4.2.4

Objednávka a dodávka pokrmu a nápoje

Diagram popisuje proces objednávky pokrmu a nápoje. Aktivita zaˇcíná vytvoˇrením objednávky zákazníkem. Pokud je na objednávce i pokrm, odešle se objednávka i do kuchynˇe,

ˇ ˚ UŽITÍ 4.3. MODEL PRÍPAD U

23

kde Kuchaˇri zaˇcnou pracovat na pˇrípravˇe pokrmu. Nápoj vyˇrídí cˇ íšníci za barem a následnˇe ho odnesou zákazníkovi. Stejnˇe se vyexpeduje i hotový pokrm. Diagram aktivit se nachází v pˇríloze D.1

4.3

Model pˇrípadu˚ užití

Pˇrípad užití je popis cˇ innosti, která je vykonávána informaˇcním systémem. Obecnˇe by se dalo rˇ íci, že pˇrípad užití je seznam kroku˚ popisující interakci mezi systémem a uživatelem (tzn. rolí). Rolí muže ˚ být cˇ lovˇek nebo externí systém.

4.3.1

Správa systému

Diagram pˇrípadu˚ užití správa systému definuje základní množinu operací pro správu celého systému. Všechny tyto operace muže ˚ vykonávat uživatel s právy Vedoucího, nebo cˇ ásteˇcnˇe i ostatní povˇerˇ ení uživatelé. Všechny pˇrípady užití mají podobnou logiku. Povˇerˇ ený uživatel muže ˚ zobrazovat záznamy, vytváˇret nové záznamy, editovat a mazat stávající záznamy týkající se nastavení informaˇcního systému. Diagram pˇrípadu užití se nachází v pˇríloze D.3

4.3.2

Objednávka a zhotovení pokrmu a nápoje

Diagram pˇrípadu˚ užití objednávka a zhotovení pokrmu a nápoje popisuje jednotlivé cˇ innosti, které souvisí s objednávkou a pˇrípravou pokrmu a nápoje. ˇ ˇ Z pohledu Kuchaˇre a Cíšníka se cˇ innosti podobají. Kuchaˇr pˇripravuje pokrmy a Cíšník nápoje. Po pˇrípravˇe je nastaven status objednávky na hotovo.

Obrázek 4.6: Diagram pˇrípadu˚ užití - Pˇríprava pokrmu a nápoje


24

ávka a

skladu

oje ení náp

zhotov

rmu

ení pok zhotov

u systém

ávka a Objedn

Objedn

Správa

Správa

Správa zamˇestnancu˚ Správa surovin Pˇríprava nápoje Pˇríprava pokrmu Zaplacení útraty Zobrazení stavu Zmˇena stavu objednávky Vložení nového záznamu Editování záznamu Zobrazení záznamu

X X X X

X X X

X X X X

X X X

X X X

X

X

Tabulka 4.1: Mapování požadavku˚ na model pˇrípadu˚ užití

4.4

Mapování požadavku˚ na model pˇrípadu˚ užití

Mapování funkˇcních požadavku˚ na jednotlivé pˇrípady užití slouží ke kontrole, zda je každý funkˇcní požadavek pokryt alesponˇ jedním pˇrípadem užití. Pro lepší vizuální pˇrehled se vytváˇrí tabulka. Do prvního sloupce tabulky se napíší pˇrípady užití. Do prvního rˇ ádku se napíší funkˇcní požadavky na informaˇcní systém. Smyslem této tabulky je tedy znázornit, že každý funkˇcní požadavek se váže alesponˇ k jednomu pˇrípadu užití.

4.5. DOMÉNOVÝ MODEL

4.5

25

Doménový model

Doménový model je jedna z forem diagramu tˇríd. Diagramy tˇríd se používají pˇri objektovém návrhu softwaru. Základním stavebním kamenem diagramu tˇríd je tˇrí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ˇe nezávislý. Struktura tˇríd je tak zjednodušená. Doménový model je první ucelený pohled na budoucí informaˇcní systém. Pˇri tvorbˇe modelu se vychází z požadavku˚ zákazníka. Ze zadání se nejprve identifikují klíˇcové entity, duležité ˚ atributy a vztahy mezi entitami. Entity se zakreslí do modelu jako tˇrídy. Dle grafické notace jazyka UML se tˇrídy zakreslují jako obdélníky vodorovnˇe rozdˇelené na tˇri cˇ ásti. Doménový model pro zadaný informaˇcní systém je navržen na principu popsání celého systému pomocí tˇríd. Mezi tˇrídami se využívá vˇetšiny základních vztahu. ˚ Nejprve se zamˇerˇ íme na tˇrídy Category a CategoryMember. Mezi tˇemito tˇrídami je agregaˇcní vztah (viz 4.5.1). Objekty tˇrídy CategoryMember sice mohou v systému existovat i bez urˇcené categorie, ale nemají v systému další stˇežejní využití. Diagram doménový model je v pˇríloze D.4 Vztah kompozice (viz. 4.5.1), tedy silnˇejší vztah mezi tˇrídami, je mezi tˇrídami Person a Position, Adress, Phone, Email, Timesheet. Všechny tyto vztahy by nemˇely žádný význam, kdyby neexistovala instance tˇrídy Person, ke které by se položky mohly pˇriˇradit.

4.5.1

Vztahy mezi entitami

V jazyce UML existuje nˇekolik základních vztahu˚ mezi entitami. • Asociace je základní vztah mezi tˇrídami. Tˇrídy mohou existovat nezávisle na sobˇe. Ve výchozím stavu je entita obousmˇerná, tzn. první tˇrída má odkaz na druhou a naopak. • Agregace reprezentuje vztah typu celek - cˇ ást. Znázornuje ˇ se jako jednoduchá plná cˇ ára, zakonˇcená na jedné stranˇe prázdným kosoˇctvercem. Ten je umístˇen u té entity, která reprezentuje celek. Entita reprezentující cˇ ást muže ˚ existovat sama o sobˇe a být souˇcástí i jiných kolekcí. • Vztah kompozice je velmi podobný vztahu agregace. Kompozice tvoˇrí silnˇejší vztah mezi entitami (tˇrídami). Pokud zanikne tˇrída reprezentující celek, automaticky zanikají všechny ostatní cˇ ásti. • Poslední ze základních vztahu˚ mezi tˇrídami v UML diagramu je vztah generalizace (dˇediˇcnosti). Z pohledu programování se jedná o vztah dˇediˇcnosti. První entita zdˇedí všechny vlastnosti rodiˇcovské entity a dále si muže ˚ svoje chování pˇresnˇeji upravit. • Násobnost urˇcuje kolik entit jednoho typu muže ˚ odkazovat na jednu entitu typu druhého. Existují 3 základní typy násobnosti. – cˇ íslo - oznaˇcuje pˇresný poˇcet entit (vˇetšinou se používá 1). – hvˇezdiˇcka - oznaˇcuje libovolný poˇcet, vˇcetnˇe 0. – interval - vyznaˇcuje pˇresný poˇcet odkazu˚ v mezích intervalu, napˇr. 0..1, 1..*, 3..5, atd.


26

4.6

Stavové diagramy

Stavový diagram slouží k názornému zobrazení životního cyklu entity. Stavový diagram popisuje stavy, kterých muže ˚ entita nabývat. Dalo by se rˇ í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 - cˇ innost. Zatímco stavový diagram popisuje stavy právˇe jedné entity.

4.6.1

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ˇeru zákazníkem se položka pˇridá na objednávku, dokud se výbˇer závaznˇe nepotvrdí, tak se položky (pokrmy ani nápoje) nikam neodešlou. Po závazném objednání se pokrmy odešlou do kuchynˇe a nápoje na bar. Na dobu, kdy je položka v pˇrípravˇe, jsou tˇri stavy (objednáno, v pˇrípravˇe a hotovo). Po doruˇcení položky zákazníkovi následuje stav zaplaceno, pokud je vše v poˇrádku, nebo odmítnuto, pokud zákazník položku odmítl pˇrijmout.

Obrázek 4.7: Stavový diagram - Položka objednávky

4.6.2

Objednávka

Stavový diagram popisuje stavy objednávky. Objednávka vzniká prvním výbˇerem pokrmu nebo nápoje zákazníkem. Pˇri vzniku objednávky se automaticky pˇresune do stavu Nezaplaceno. Pokud zákazník zaplatí vše, co si objednal, pˇresune se objednávka do stavu Zaplaceno. V informaˇcním systému musí být také možnost objednávku zrušit. At’ je to z du˚ vodu platební neschopnosti zákazníka cˇ i pˇredˇcasným odchodem, atd. V každém pˇrípadˇe je potˇreba objednávku v informaˇcním systém uzavˇrít. Pro tyto pˇrípady je zde stav Zrušeno. Stavový diagram je v pˇríloze D.2

4.7. ANALYTICKÝ MODEL

4.6.3

27

Surovina

Stavový diagram popisuje stavy suroviny na skladˇe. Po doplnˇení objednané suroviny na sklad se nastaví stav suroviny na „Dostatek suroviny“. Kuchaˇr pˇri vaˇrení odebírá surovinu ze skladu. Pokud množství suroviny klesne pod stanovený limit, zmˇení se stav suroviny na „Minimální stav surovin“. Z tohoto stavu je možné se pˇresunout do stavu „Dostatek surovin“ v pˇrípadˇe, že dojde k doplnˇení zásob. Pokud je stav „Minimální stav surovin“, není možné dále objednávat pokrmy a nápoje, které potˇrebují k pˇrípravˇe 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ˇejší než doménový model. Tˇrídy v analytickém modelu musí obsahovat datové typy všech svých atributu. ˚ Nejen z toho plyne, že analytický model je platformnˇe závislý a specifický pro urˇcitý programovací jazyk. V názvu tˇríd, atributu˚ a metod se nesmí vyskytovat diakritika (v doménovém modelu diakritika být mohla). Existuje nˇekolik oprávnˇených du˚ vodu, ˚ proˇc musí být analytický model domyšlený do detailu. V první rˇ adˇe není možné u složitých informaˇcních systému v prubˇ ˚ ehu programování zmˇenit logiku problému. Dalším duvodem ˚ jsou finance. Analytický model vytvoˇrí zkušený programátor (analytik) a samotné programování provede ménˇe zkušenˇejší, který bude zárovenˇ levnˇejší. Diagram analytického modelu pro zadanou úlohu specifikuje a doplnuje ˇ doménový model (viz. D.4). Do diagramu jsou doplnˇeny datové typy jednotlivých atributu˚ tˇríd, návratové datové typy metod a vstupních parametru. ˚ Dále je kladen duraz ˚ na zapouzdˇrení tˇríd a atributu. ˚ Diagram analytického modelu je v pˇríloze D.5.

4.8

Databázový model

Relaˇcní databázový model patˇrí mezi nejpoužívanˇejší databázové modely, zárovenˇ také patˇrí 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ˇe stanoveného poˇctu sloupcu˚ a rˇ ádku. ˚ Všechny operace se pak provádˇejí nad celými tabulkami, jednotlivými sloupci, rˇ ádky nebo samostatnými bunkami. ˇ


28

Pro práci s databází se používá Hibernate, který namapoval jednotlivé databázové tabulky na tˇrídy. Databázové tabulky tedy odpovídají tˇrídám z analytického modelu. Hlavním duvodem ˚ pro vytvoˇrení databázového modelu je zachycení všech pˇrípadu, ˚ pˇri kterých se bude pracovat s databází (ukládání nebo cˇ tení dat).

4.9

Model nasazení

Diagram modelu nasazení ukazuje hardware, na kterém bude vytváˇrený software nasazený. Dále také popisuje konkrétní nasazení softwaru (tzn. vazby mezi jednotlivými komponentami). V diagramu jsou znázornˇeny jednotlivé komponenty, které je potˇreba nastavit, aby mohl informaˇcní systém bezchybnˇe pracovat.

Obrázek 4.9: Diagram modelu nasazení

Kapitola 5

Realizace Kapitola popisuje tvorbu uživatelského rozhraní a aplikaˇcní logiky celého informaˇcního systému. Nejprve je popsán model architektury. V další cˇ ásti kapitoly je popsána tvorba uživatelského rozhraní. Dále kapitola obsahuje samotný popis implementace. Z duvodu ˚ velkého rozsahu je hlavní duraz ˚ kladen na stˇežejní cˇ ásti systému.

5.1

Model architektury

Model architektury se rˇ adí do poˇcetné skupiny UML diagramu. ˚ Úkolem diagramu je graficky znázornit struktury architektury a pˇrípadné vazby mezi jednotlivými vrstvami. Pˇríloha D.6 zobrazuje rozdˇelení architektury informaˇcního systému na tˇri vrstvy. Datová vrstva (na diagramu se nazývá model) se stará o komunikaci s databází. Aplikaˇcní logika celého systému se nachází ve druhé vrstvˇe. Tato vrstva se nazývá controller. Poslední, tˇretí vrstva se stará o zobrazení výsledku˚ uživateli. Vrstva nese název view. Z webového prohlížeˇce je pˇrístupná pouze poslední vrstva a uživatel pˇrímo komunikuje pouze s ní.

5.2

Návrh uživatelského rozhraní

Tato kapitola se vˇenuje popisu hlavních cˇ ástí uživatelského rozhraní. Uživatelské rozhraní je pro uživatele velmi duležité. ˚ V pˇrípadˇe kvalitního uživatelského rozhraní uživatelum ˚ usnadnuje ˇ používání celého systému. V kapitole 4.1.2 Aplikaˇcní frameworky jsou uvedeny technologie, které byly použity pro potˇreby programování aplikace.

29

30

KAPITOLA 5. REALIZACE

Základní rozvržení Základní rozvržení je rozdˇeleno do tˇrí cˇ ástí. V horní cˇ ásti se nachází hlavní menu celé aplikace (v závislosti na uživatelské roli se zobrazí pˇríslušná nabídka). V prostˇrední cˇ ásti se nachází hlavní obsah pˇríslušné stránky. V zápatí celé stránky je informaˇcní lišta.

Obrázek 5.1: Základní layout informaˇcního systému

Správa zamˇestnancu˚ Komponenta správa zamˇestnancu˚ zobrazí v tabulce všechny zamˇestnance. Mezi funkce patˇrí vytvoˇrení nového zamˇestnance, pˇrípadná editace jeho údaju˚ nebo odstranˇení zamˇestnance ze systému. U každého zamˇestnance je dále možné zobrazit jeho detail, výkaz práce (tzv. timesheet) a v neposlední rˇ adˇe také objednávky, které v systému vytvoˇril. Obrázek s návrhem se nachází v pˇríloze C.1 Správa jídelníˇcku Na obrázku 5.2 je vidˇet názorná ukázka, jak se zobrazí jednotlivé kategorie pokrmu˚ a nápoju. ˚ Uživatel bude moci tyto kategorie editovat. Souˇcástí editace je také pˇridání dalších položek do zvolené kategorie.

Obrázek 5.2: Zobrazení kategorie nápoju. ˚ Vstupem uživatele na stránku se zobrazí seznam všech kategorií pokrmu˚ nebo nápoju, ˚ které se nacházejí v jídelníˇcku. Kategorii je možné editovat i smazat. V editaci je možné pˇridávat/odebírat jednotlivé.

5.2. NÁVRH UŽIVATELSKÉHO ROZHRANÍ

31

Položky na jídelním lístku Vedoucí nebo jím povˇerˇ ený uživatel také bude moci spravovat (pˇridávat, editovat a mazat) jednotlivé položky jídelního lístku. Na obrázku 5.3 je názornˇe ukázáno jak bude vypadat seznam pokrmu˚ a nápoju. ˚ Po zobrazení detailu se zobrazí postup pˇrípravy zvolené položky, dále seznam potˇrebných surovin pro výrobu jedné porce a informace o nákupní a prodejní cenˇe. Tyto informace zobrazuje obrázek v pˇríloze C.2

Obrázek 5.3: Zobrazení seznamu položek v jídelníˇcku. Vstupem uživatele na stránku se zobrazí seznam všech pokrmu˚ nebo nápoju, ˚ které se nacházejí v jídelníˇcku. Položky je možné pˇridávat, editovat nebo smazat. V editaci je možné upravovat seznam surovin pro pˇrípravu.

Prostˇredí restaurace ˇ Po zvolení režimu Cíšník se nejprve zobrazí seznam stolu˚ (viz. pˇríloha C.3), pokud u stolu bude vytvoˇrena objednávka, zobrazí se struˇcné informace (jméno zamˇestnance, celková hodnota objednávky). V opaˇcném pˇrípadˇe se po výbˇeru stolu objednávka vytvoˇrí. 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ˇcní tlaˇcítka pro operace s objednávkou. Pod informacemi o objednávce se nachází jídelní lístek. V pravé cˇ ásti obrazovky je seznam objednaných položek spoleˇcnˇe 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 vytvorˇ ené objednávce, dále informace o stolu. V hlavní cˇ ásti stránky se nachází jídelní lístek a v pravé cˇ ásti seznam objednaných položek spoleˇcnˇe s cenou a stavem.

32


Prostˇredí kuchynˇe / baru Prostˇredí kuchynˇe a baru vypadá stejnˇe. 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 mužeme ˚ vidˇet položky ve tˇrech sloupcích, podle toho, v jakém stavu se daná položka nachází.

Obrázek 5.5: Prostˇredí baru / kuchynˇe. Celá stránka je rozdˇelena do tˇrech sloupcu˚ podle stavu. ˚ V každém sloupci je zobrazen vždy stul, ˚ který má na objednávkovém lístku položku v odpovídajícím stavu, cˇ as poslední zmˇeny stavu a akce, kterou je možné s položkou vykonat.

Sklad surovin Režim Skladník obsahuje tˇri základní funkcionality. V této cˇ ásti kapitoly se zamˇerˇ íme pouze na dvˇe z nich - Kategorie suroviny a Suroviny. Kategorie surovin obsahuje seznam kategorií, do kterých jsou suroviny na skladˇe rozdˇeleny. Pˇríslušná stránka vypisuje seznam do pˇrehledné tabulky. V každém rˇ ádku je název kategorie, popis (nebo nˇejaké poznámky), celkový poˇcet položek v kategorii, jakou hodnotu mají suroviny v kategorii. V posledním sloupci tabulky se nachází navigaˇcní lišta pro editování nebo smazání kategorie. V posledním rˇ ádku tabulky se zobrazena celková cena všech položek na skladˇe. Návrh uživatelského rozhraní je zobrazen v pˇríloze C.5. Stránka zobrazující obsah jednotlivé kategorie surovin (ukázka je v pˇríloze C.4) obsahuje v levé cˇ ásti seznam kategorií surovin a v pravé cˇ ásti pˇrehlednou tabulku s výpisem jednotlivých položek zvolené kategorie. Každý rˇ ádek výpisu se týká jedné suroviny a obsahuje název, jednotku, v níž se surovina mˇerˇ í, cenu za uvedenou jednotku, celkovou cenu na suroviny na skladˇe a poslední sloupec opˇet zobrazuje navigaˇcní tlaˇcítka. V posledním rˇ ádku tabulky je souˇcet všech položek v kategorii a celková cena za kategorii.

5.3. POPIS IMPLEMENTACE

5.3

33

Popis implementace

Pro implementaci informaˇcního systému byla zvolena tˇrívrstvá architektura typu MVC1 . Jako první je popsána modelová vrstva - tedy práce s úložištˇem dat. Pro komunikaci s databází byl vybrán objektovˇe relaˇcní framework Hibernate (viz. kapitola 4.1.2.1). Aplikace využívá model rozdˇelený do dalších samostatných vrstev. Nyní se na nˇekteré vrstvy podíváme podrobnˇeji. Jednou z vrstev jsou entity. Entita je tˇrí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ˇrídy se nacházejí v balíˇcku eu.petrvich.ris.domain. Dále model obsahuje servisní vrstvu, která se nachází v balíˇcku eu.petrvich.ris.service.dao. Dalo by se rˇ íci, že servisní vrstva plní roli cˇ ehosi jako fasády nad jednotlivými entitami. Poslední vrstvou modelu kterou si zde pˇredstavíme, je vrstva Repository. Tˇrídy této vrstvy se nacházejí v balíˇcku eu.petrvich.ris.service.impl a jsou potomky tˇrídy HibernateDaoImp, ve které jsou implementovány metody pro základní práci s databází. V další cˇ ásti kapitoly se podíváme na controller. Veškeré požadavky, které pˇrijdou, rˇ eší pˇríslušný controller, který se vybere podle url adresy. Veˇrejné metody v controlleru jsou datového typu ModelAndView, díky kterému v metodˇe snadno nastavíme, jaké view má daný obsah zobrazit, a také snadno pˇredáme parametry pro jeho vykreslení. Controller nikdy pˇrímo nepracuje s databází, ale využívá k tomu právˇe modelovou vrstvu, konkrétnˇe servisní tˇrídy. Pro celou aplikaci je vytvoˇrena abstraktní tˇrída BaseController, ve které jsou definovány všechny instance na servisní tˇrídy. Tˇrída BaseController je pˇrímým potomkem tˇrídy AbstracController. V balíˇcku web se také nachází balíˇcek validators, který obsahuje tˇrídy pro validaci formuláˇru˚ a také balíˇcek editors. Tˇrídy v baliˇcku editors usnadnují ˇ práci pˇri pˇredání celého objektu, protože na základˇe unikátní informace (v našem pˇrípadˇe se jedná o unikátní parametr id) o objektu dokáží z databáze naˇcíst opˇet celý objekt. Poslední cˇ ástí aplikace je vrstva view. Tato vrstva se nachází v adresáˇri „WEB-INF/views“. Adresáˇr obsahuje JSP soubory, které se starají o vykreslení dat uživateli. Layout celé aplikace je tvoˇren, jak již bylo zmínˇeno, pomocí Apache Tiles. Konfigurace layoutu se nachází v „WEB-INF/tiles/tile-definition.xml“. Tento soubor obsahuje konfiguraci pro jednotlivé typy layoutu. ˚ Zde se definuje na jaké stránce (respektive jaké skupinˇe stránek) se zobrazí konkrétní cˇ ást layoutu, atd. <definition name="defaultTemplate" template="/WEB-INF /template/default/template.jsp"> 1

MVC - Model-View-Controler. Architektura popisuje logickou strukturu systému a oddˇelení bussiness logiky od uživatelského rozhraní.

34


Kapitola 6

Testování Jedním z posledních kroku˚ pˇri návrhu systému je testování softwaru. Pˇred nasazením programu do ostrého provozu je potˇreba jej rˇ ádnˇe otestovat a ovˇerˇ it, zda se informaˇcní systém chová tak, jak má a jak bylo pˇri analýze domluveno se zákazníkem. Na první pohled se muže ˚ testování zdát jako zbyteˇcné protahování vývoje a bezpˇredmˇetné navyšování ceny. V každé literatuˇre, která se vˇenuje návrhu softwaru, je však na testování kladen veliký du˚ raz. Pˇri pravidelném testování je možné odhalit závažné chyby již ve stadiu vývoje a tím ušetˇrit drahocenný cˇ as jak programátoru, ˚ tak testeru, ˚ a ušetˇrit tím nemalé prostˇredky, které by se musely vynaložit na opravu chyb.

6.1

Kategorie testu˚

Softwarové testy je možné rozdˇelit do nˇekolika kategorií. Testy se mohou dˇelit podle zpu˚ sobu použití (zátˇežové, usability - testování uživatelského rozhraní, alfa testy, beta testy), atd.

6.1.1

Testování programátorem

Test se provádí bezprostˇrednˇe po dopsání nˇejaké logické cˇ á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.

6.1.2

Usability test

Usability test je typ testování se zákazníkem. Jedná se o testování uživatelského rozhraní. 6.1.2.1

Low fidelity prototype

Testování pomocí „Low fidelity prototype“ se využívá hlavnˇe v raných fázích vývoje aplikace, kdy ještˇe není hotový design aplikace, ale je zapotˇrebí otestovat, zda bude vymyšlené uživatelské rozhraní budoucím uživatelum ˚ vyhovovat. Velmi cˇ asto se k tomuto typu

35

36

KAPITOLA 6. TESTOVÁNÍ

testování používá pouze papír, na kterém jsou pˇredem pˇripravené jednotlivé obrazovky systému. Podle toho jak se uživatel rozhodne, mˇení moderátor testu jednotlivé obrazovky. Pˇred zahájením programování celé aplikace byl vytvoˇrený low fidelity prototype. S tímto prototypem bylo provedeno nˇekolik diskuzí s lidmi s oboru gastronomie a pˇrípadnými zákazníky výsledného softwaru. Nˇekteré požadavky byly zakomponovány do návrhu aplikace a nˇekteré byly pˇresunuty do budoucí verze programu. Pro potˇreby testu bylo vytvoˇreno celkem 5 scénáˇru. ˚ V další cˇ ásti kapitoly budou podrobnˇe popsány scénáˇre jednotlivˇe. Úvodní obrazovka Na tomto scénáˇri se zobrazuje výbˇer jednotlivých rolí celého systému. Uživatel si v této fázi muže ˚ zvolit, v jaké roli chce se systémem pracovat. Tento scénáˇr dále dokáže zprostˇredkovat pˇrihlášení zamˇestnance na smˇenu. Role Vedoucí Scénáˇr Vedoucí zobrazuje jednotlivé funkce této role. V rámci testu je možné si prakticky vyzkoušet v omezené míˇre veškeré funkcionality této role, jako je vytvoˇrení nové kategorie pokrmu˚ i nápoju, ˚ dále vytváˇrení nových pokrmu˚ a nápoju, ˚ spoleˇcnˇe s pˇriˇrazením surovin pro pˇrípravu. Scénáˇr dále zobrazuje veškerou funkcionalitu, kterou role umožnuje. ˇ Role Skladník Podobnˇe jako pˇredchozí scénáˇr zobrazuje jednotlivé funkce role Vedoucí, tak i tento scénáˇr zobrazuje jednotlivé funkce role Skladník. Scénáˇr pˇredstavuje jednotlivé obrazovky, se kterými bude tento uživatel pracovat. ˇ Role Cíšník ˇ Tento scénáˇr zprostˇredkovává jak bude vypadat role Cíšník. V prvním kroku scénáˇr zobrazuje seznam stolu˚ v restauraci. Po výbˇeru stolu se zobrazí detail konkrétního stolu. Na detailu se zobrazí podrobné informace o vybraném stolu, navigaˇcní tlaˇcítka a celková cena objednaných položek. Dále se zobrazí jídelní lístek a v poslední cˇ ásti obrazovky se zobrazí seznam objednaných položek spoleˇcnˇe s cenou a stavem fáze pˇrípravy, ve které momentálnˇe jsou. Role Kuchaˇr a Barman Poslední scénáˇr zobrazuje spoleˇcnou funkcionalitu pro dvˇe role v systému, a to pro roli Kuchaˇr a Barman. Celá obrazovka je rozdˇelena do tˇrí sloupcu. ˚ V prvním sloupci se zobrazují položky se stavem „objednáno“, ve druhém sloupci se zobrazují položky ve stavu „v pˇrípravˇe“ a v posledním sloupci se zobrazují položky se stavem „pˇripraveno“. Jednotlivé objednávky se rozdˇelují podle stolu, na kterém byla objednávka vytvoˇrena, a u každé položky se také zobrazuje cˇ as poslední zmˇeny stavu konkrétní položky. Celý test je zaˇrazen jako pˇríloha na konci textu práce.

˚ 6.1. KATEGORIE TESTU

37

Výsledky low-fidelity prototype testu Bˇehem testování bylo objeveno nˇekolik funkcí systému, které by v praxi práci se systémem spíše komplikovaly, a proto byly z návrhu systému odstranˇeny. Dále také byly, ve spolupráci s úˇcastníky testu, do systému pˇridány, popˇrípadˇe editovány další funkce pro práci se systémem. Nˇekteré funkce byly zaˇrazeny do další verze. Ze systému byly odebrány následující funkce. • Uzamknutí stolu pouze pro konkrétního cˇ íšníka - v první verzi návrhu informaˇcního systému plánování vytvoˇrit zámek na konkrétní stul ˚ pouze pro jednoho cˇ íšníka. Po diskuzi byla tato funkce oznaˇcená za zbyteˇcnou a komplikující práci cˇ íšníkum. ˚ • Vytvoˇrení objednávky surovin dle dodavatele - Skladník by mohl vytváˇret opakující se objednávky dle dodavatele. S ohledem na možnou zmˇenu ceny a také na veliký výbˇer dodavatelu˚ by tato funkce byla zbyteˇcná. Dále do systému byla pˇridána tato rozšíˇrení • Pˇridání stavu položek na objednávce - v první verzi návrhu systému mˇela položka na objednávce pouze tˇri stavy (objednáno, v pˇrípravˇe, hotovo). Bˇehem testování vznikaly sporné situace, v jakém stavu je daná položka. Byly tedy pˇridány další stavy (vybráno, doruˇceno, zaplaceno a stornováno, pro lepší identifikaci a kontrolu objednané položky. • Detail objednávky ve výpisu stolu˚ - Pˇri výpisu seznamu stolu˚ se nejprve zobrazovalo cˇ íslo a kapacita stolu. Nebylo tedy na první pohled poznat zda má stul ˚ vytvorˇ enou objednávky. Na doporuˇcení byl rozšíˇren popis stolu o informace vytvoˇrené objednávky (cena, jméno zamˇestnance a poˇcet položek). Zustává ˚ nˇekolik požadavku, ˚ které budou implementovány v další verzi. • Vytváˇrení pˇridružených skladu˚ - Pro lepší fungování baru a kuchynˇe by se zamˇestnancum ˚ hodilo mít nˇekteré suroviny na svém pracovišti. Zárovenˇ je také potˇreba aby ˇ i tyto suroviny byly pod kontrolou informaˇcního systému. Rešením této situace je vytvoˇrení vedlejších skladu˚ a pˇresuny potˇrebných surovin z hlavního skladu do skladu˚ pˇridružených. • Poˇcítání nákupní ceny suroviny - v souˇcasném rˇ ešení je pro všechny suroviny jednoho typu stanovena jedna konkrétní cena. Ceny se ale mohou v prubˇ ˚ ehu naskladnování ˇ surovin mˇenit. Bylo by dobré do systému pˇridat poˇcítání prumˇ ˚ erné nákupní ceny. • Sledování trvanlivosti surovin - Ve skladu se vyskytují suroviny, které byly nakoupeny v rozdílném cˇ asovém horizontu. Systém by mohl toto sledovat a informovat skladníka o surovinách s konˇcící lhutou ˚ trvanlivosti.

38


6.1.2.2

Testování hotového systému

Pro toto testování se používají dvˇe základní metody. První metodou je kognitivní pruchod. ˚ Zadavatel testu pˇripraví nˇekolik scénáˇru˚ na pruchod ˚ jednotlivých cˇ ástí. Hodnotí se, zda uživatel pochopil zadání úkolu, zda ví, jak má pokraˇcovat, a na závˇer, zda systém zobrazil výsledek úkolu (úspˇech nebo neúspˇech). Druhá metoda se jmenuje Heuristická evaluace. Heuristická evaluace obsahuje seznam pravidel, která by nemˇel testovaný software porušovat.

6.2

Postup testování

Pˇred zahájením testování se musí zajistit dostateˇcný poˇcet lidí, kteˇrí systém otestují. Pro výbˇer správných testeru˚ 1 se používá screener2 . Korektnˇe sestavený screener nesmí prozradit, o jaký produkt k testování se jedná, ale zárovenˇ musí odhalit, že uživatel splnuje ˇ minimální požadavky pro zvládnutí testu. Skreener otázka

možnosti

Pracujete v oboru gastronomie? Kolik Vám je let? Jak cˇ asto chodíte do restaurace Pracujete na vedoucí pozici?

ANO / NE

požadovaný poˇcet lidí [v %] 50%, 50%

do 25 / 26-33 / 34- 40 / 40+ vubec ˚ / obˇcas / cˇ asto

10%, 35%, 45%, 10% 0%, 20%, 80%

ANO / NE

75%, 25%

Tabulka 6.1: Screener pro výbˇer uživatelu˚ k testování Vyhodnocením screeneru se provede výbˇer lidí, kteˇrí mají potenciál software korektnˇe otestovat. Pˇred samotným zahájením testu je testerovi pˇredložen tzv. pre-test3 . Po vyplnˇení pre-testu zaˇcíná samotný test uživatelského rozhraní.

1

Tester - osoba, která testuje zaˇrízení, nebo software. Screener - anonymní test nabídnutý velké množinˇe potencionálních testeru. ˚ Po vyplnˇení testu se dle pˇredem stanovených pravidel (pravidla urˇcuje zadavatel testu) rozhodne, zda je tester pro náš test vhodný. 3 Pre-test - seznam otázek, které mají pomoci navodit pˇríjemnou atmosféru testera s moderátorem testu. 2

6.2. POSTUP TESTOVÁNÍ

39

Test uživatelského rozhraní

Test uživatelského rozhraní se skládá z nˇekolika pˇredem pˇripravených scénáˇru, ˚ které musí uživatel projít a v prubˇ ˚ ehu jednotlivé úkoly hodnotit.

1. Scénáˇr - Vytvoˇrte 3 nové uživatele. Prvnímu nastavte roli vedoucí, druhému kuchaˇr a tˇretímu cˇ íšník. Po dokonˇcení první cˇ ásti druhému uživateli zmˇente ˇ jméno a tˇretího uživatele vymažte.

2. Scénáˇr - Vytvoˇrte 5 surovin s libovolným množstvím na skladˇe. Dále vytvoˇrte 4 nové položky. K vytvoˇrení položek použijte Vámi vytvoˇrené suroviny. Všechny nápoje pˇrirˇ ad’te do jedné kategorie. Stejnˇe tak všechny pokrmy do jedné kategorie.

3. Scénáˇr - Vytvoˇrte novou objednávku pokrmu˚ a nápoju. ˚ Objednávku dokonˇcete a zaplat’te.

4. Scénáˇr - Vytvoˇrte novou objednávku surovin, kterou také dokonˇcíte.

5. Scénáˇr - Zapište u libovolného zamˇestnance pˇríchod do práce.

Post-test

Post-test slouží ke zhodnocení pocitu˚ z testu, pro odlehˇcení atmosféry v pˇrípadˇe, že testerovi se moc nedaˇrilo. Po dokonˇcení post-testu konˇcí i celé testování s uživatelem.

40


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ˇelíme do 3 skupin (1 - kritická chyba, 2 - chyba, která nemá vliv na funkˇcnost, ale vˇetšinˇe zákazníku˚ pusobí ˚ komplikace, 3 - drobná chyba). Pˇri testování s uživateli byly zjištˇeny následující nálezy: nález Pˇri zadání velkého cˇ ísla do pole plat aplikace skonˇcila chybou.

scénáˇr 1.

skupina 1

Pokud je zadaná adresa, email, telefon ve špatném poli a uživatel se pˇrepne do jiné karty, formuláˇr se neodešle, ale chybová hláška zustane ˚ skrytá. Pˇri zadání velkého poˇctu surovin pˇri vytváˇrení objednávky, nebo suroviny. Hodnota suroviny se zobrazí ve formátu exponentu - pouze u cˇ ísel vˇetších než milion.

1.

2

3. a 4.

2

opraveno ANO - nastavení omezení pro délku cˇ ísla ve formuláˇri. NE - Chyba bude opravena v další verzi. NE - Chyba bude opravena v další verzi.

Tabulka 6.2: Nálezy testování aplikace s uživateli. Pˇri testování aplikace s uživateli byly identifikovány nálezy sepsané v tabulce 6.2.

Kapitola 7

Závˇer 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ˇeny jednotlivé body zadání. V implementaci jsou splnˇeny všechny požadavky, které jsou uvedeny v zadání.

Osobní cíle V úvodu celé práce jsem si stanovil nˇekolik osobních cílu, ˚ které mˇe 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ˇri programování použity. Díky této práci jsem se nauˇcil vytváˇret aplikace na platformˇe Java EE s podporou aplikaˇcní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ˇekterými technologiemi jsem se setkal i dˇríve, ale první praktickou zkušenost mám až díky bakaláˇrské práci.

Rešerše a porovnání systému˚ Komerˇcní výrobky, se kterými se návrh porovnává v kapitole 3.6, mají sice nˇekteré nedostatky, ale jedná se o produkty, které jsou na cˇ eském trhu rˇ adu let a stále na vývoji pracuje tým programátoru. ˚ Informaˇcní systém, který je pˇredmˇetem této práce, je jistˇe konkurenceschopný komerˇcním rˇ ešením.

Pˇrínos práce Tato práce má velký potenciál a rozhodnˇe by mohla být pˇrínosná i pro komerˇcní využití. Pokud pujde ˚ vše podle plánu, mˇel by být informaˇcní systém bˇehem letních prázdnin nasazen do ostrého provozu.

41

ˇ KAPITOLA 7. ZÁVER

42

Rozšíˇrení systému Informaˇcní systém by bylo možné rozšíˇrit o další nové funkcionality. Implementováno by napˇríklad mohlo být následující: • Doprogramovat podporu pro používání dílˇcích skladu˚ (samostatný sklad pro bar, kuchyn). ˇ • Systém by dále mohl podporovat rozmístˇení stolu˚ v restauraci, pˇrípadnˇe rozdˇelení stolu˚ do více místností (napˇríklad salonek, zahrádka atd.) • Internetová rezervace stolu v restauraci. • Podpora sociálních sítí. Informaˇcní systém by se mohl starat o automatické zobrazování akˇcních nabídek a denního menu na sociálních sítích. • Rozšíˇrit informaˇcní systém na mobilní zaˇrízení (mobilní telefon, tablet). • Objednávání surovin by se mohlo rozšíˇrit o cˇ teˇcku cˇ árových kódu˚ a umožnit zamˇestnanci objednávat zboží pouhým pˇreˇctením kódu v obchodˇe.

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 9781-849512-70-1. [2] BURD, Barry. JSP: Javaserver pages, podrobný pruvodce. ˚ Vyd. 1. Praha: Computer Press, 2003, 381 s. ISBN 80-722-6804-X. [3] ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektovˇe orientovaná analýza a návrh prakticky. Vyd. 1. Pˇreklad Bogdan Kiszka. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9. [4] Entprice Java Bean. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2013-11-15]. Dostupné z: <en.wikipedia.org/ wiki/Enterprise_JavaBeans> [5] EXtensible Markup Language. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2014-02-22]. Dostupné z: <en. wikipedia.org/wiki/XML> [6] Hibernate Quick Guide. In: Tutorials Point [obrázek]. Hibernate Quick Guide, 2014 [cit. 2014-05-22]. Dostupné z: <www.tutorialspoint.com/images/hibernate_ architecture.jpg> [7] Informaˇcní systém. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2013-04-23]. Dostupné z: [8] Information System. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2014-02-22]. Dostupné z: <en.wikipedia. org/wiki/Information_system> [9] Java Message Service. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2013-10-12]. Dostupné z: <en.wikipedia. org/wiki/Java_Message_Service> [10] Overview of the Spring Framework. In: Overview of the Spring Framework [obrázek]. 2014 [cit. 2014-05-22]. Dostupné z: <docs.spring.io/spring/docs/3.1.0.M1/ spring-framework-reference/html/images/spring-overview.png>

43

44

LITERATURA

[11] Simple Object Access Protocol. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2014-02-22]. Dostupné z: <en. wikipedia.org/wiki/Simple_Object_Access_Protocol> [12] SQL. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2014 [cit. 2014-02-23]. Dostupné z: <en.wikipedia.org/wiki/SQL> [13] ABRA SOFTWARE A.S. ABRA Software a.s. [online]. 2014. vyd. 2014 [cit. 2014-05-10]. Dostupné z: [14] Apache Tiles [manual]. 2014 [cit. 2014-05-12]. Dostupné z: [15] APACHE. Apaneche Maven Project [manual]. 2014, 2014-05-21 [cit. 2014-03-20]. Dostupné z: <maven.apache.org/what-is-maven.html> [16] DAVIS, Ziff. LLC. PCMAG DIGITAL GROUP. Application Frameworks: Specialized Application Frameworks [online]. 1996 [cit. 2014-05-12]. Dostupné z: <www.pcmag.com/ encyclopedia/term/37907/application-framework> [17] Git: [manual]. 2014 [cit. 2014-03-30]. Dostupné z: [18] MySQL: The world’s most popular open source database [online]. 2014 [cit. 2014-05-22]. Dostupné z: <www.mysql.com/> [19] UML [online]. 2014 [cit. 2014-03-22]. Dostupné z: [20] Apache Software Fondantion. Apache Software Fondantion [online]. 2013 [cit. 2013-0522]. Dostupné z: [21] Apache Tomcat. Apache Tomcat [online]. 2013 [cit. 2013-05-22]. Dostupné z: [22] Application Framework. JANSSEN, Cory. Application Framework [online]. 2010 [cit. 2014-05-05]. Dostupné z: [23] Bootstrap. OTTO, Mark, Jacob THORNTON, Chris REBERT a Julian THILO. Bootstrap [online]. 2014 [cit. 2014-05-10]. Dostupné z: ˇ [24] Co je aplikaˇcní server?. SKRIVÁNEK, František. Databázový svˇet [online]. 2008 [cit. 2014-05-22]. Dostupné z: [25] Databázové modely. Databáze [online]. 2010 [cit. 2014-05-22]. Dostupné z: [26] GlassFish Project – Documentation Home Page. Glassfish [online]. 2014 [cit. 2013-0522]. Dostupné z: https://glassfish.java.net/docs/project.html

LITERATURA

45

[27] Hibernate Hibernate ORM documentation. Hibernate [online]. 2014 [cit. 2014-05-15]. Dostupné z: [28] Hibernate Quick Guide. TUTORIALS POINT. Tutorials Point [online]. 2014 [cit. 201405-22]. Dostupné z: Hibernate Quick Guide [29] Java Platform, Enterprise Edition (Java EE) Technical Documentation: Java EE 7 Documentation. ORACLE. Java EE 7 Documentation [online]. 2014 [cit. 2014-05-12]. Dostupné z: [30] LaTex. LaTex [online]. 2014 [cit. 2014-01-22]. Dostupné z: [31] Microsft database. MICROSFT. Microsft database [online]. 2013 [cit. 2013-01-20]. Dostupné z: [32] PHP: Hyper Text Protocol. PHP [online]. 2014 [cit. 2013-03-22]. Dostupné z: [33] PostfreSQL. PostfreSQL [online]. 2014 [cit. 2014-02-22]. Dostupné z: [34] Spring Framework: Reference Documentation. Reference Documentation [online]. 2014 [cit. 2014-05-11]. Dostupné z: [35] Spring Framework. Tutorials Point [online]. 2014 [cit. 2014-05-02]. Dostupné z: [36] SQLite. SQLite [manual]. 2014 [cit. 2014-05-22]. Dostupné z: [37] XML Tutorial. XML Tutorial [online]. 2013 [cit. 2013-04-15]. Dostupné z: [38] Informaˇcní systémy pro firmy všech velikostí. ABRA a.s. [obrázek]. 2014 [cit. 2014-05-22]. Dostupné z: <www.abra.eu/fs/ 6b830c27-cba8-11e3-90a9-00155d09270b-comp.png> [39] Pokladní systémy VIRTUOS pro restaurace a hotely. TCP.cz [obrázek]. 2014 [cit. 201405-22]. Dostupné z: <www.tpc.cz//out/pictures/wysiwigpro/Restaurace/ kasa.jpg> [40] Vectron. Vectron [obrázek]. 2014 [cit. 2014-04-22]. Dostupné z: <www.vectron.cz/ pic/vcom2/VComL.jpg> [41] Vectron. Vectron [obrázek]. 2014 [cit. 2014-04-22]. Dostupné z: <www.vectron.cz/ pic/hotel/Pokoj_L.jpg> [42] Vectron. Vectron [obrázek]. 2014 [cit. 2014-05-22]. Dostupné z: <www.vectron.cz/ pic/sklad/ReceptyL.jpg>

46

LITERATURA

[43] Vectron. Vectron [obrázek]. 2014 [cit. 2014-04-22]. Dostupné z: <www.vectron.cz/ pic/vcom2/VCOM_Vykazy_L.jpg> [44] Vectron Systems CZ s r.o. In: Vectron Systems CZ s r.o. [online]. 2014 [cit. 2014-05-15]. Dostupné z: [45] TPC spol. s r.o. [online]. 2014 [cit. 2014-05-22]. Dostupné z:

Pˇríloha A

Seznam použitých zkratek Klient-Server - Softwarová architektura. MySQL - typ databáze. MSSQL - typ databáze. EJB - Enteprise Java Bean. Serverovˇe rˇ ízená komponenta pro správu modulární vytváˇrení aplikací. JMS - Java Message Servtice. Služba umožnující ˇ posílání zpráv mezi klienty. XML - eXtensible Markup Language. Univerzální znaˇckovací jazyk. SOAP - Simple Object Acces Protokol. Jednoduchý protokol. pro komunikaci mezi dvˇema aplikacemi. JSP - Java Server Pages. Skriptovací jazyk pro. Java EE - Java Enterprise Edition. Platforma pro vytváˇrení. 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

48

ˇ PRÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Pˇríloha B

Obsah pˇriloženého CD |-|-|-|-|--

readme.txt install.txt ris.war vichpetr-thesis-2014.pdf formular.pdf

-

|-- Apache Tomcat |-- apidocs |-- low-fidelity prototype

-

|-- text | |-- figures | |-- Hron-thesis-2009.tex |-- ris

-

tento text postup instalace aplikace zkompilovaná aplikace text práce v PDF prázdný formuláˇ r pro pr˚ uzkum existujících ˇ rešení aplikaˇ cní server dokumentace zdrojových kód˚ u adresáˇ r se soubory k low-fidelity prototype testu adresáˇ r s textem práce adresáˇ r s obrázky k práci text BP v TEX zdrojové kódy (Netbeans project)

49

50

ˇ ˇ PRÍLOHA B. OBSAH PRILOŽENÉHO CD

Pˇríloha C

Návrh uživatelského prostˇredí

Obrázek C.1: Návrh uživatelské rozhraní - seznam zamˇestnancu˚

Obrázek C.2: Návrh uživatelské rozhraní - detail pokrmu/nápoje

51

52

ˇ ˇ PRÍLOHA C. NÁVRH UŽIVATELSKÉHO PROSTREDÍ

Obrázek C.3: Návrh uživatelské rozhraní - seznam stolu˚ v restauraci


53


54

ˇ ˇ PRÍLOHA C. NÁVRH UŽIVATELSKÉHO PROSTREDÍ

Pˇrí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

56

ˇ PRÍLOHA D. UML DIAGRAMY

Obrázek D.3: Diagram pˇrípadu˚ užití - Správa systému

57

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

58


Obrázek D.5: Diagram Analytický model

59

Obrázek D.6: Diagram modelu architektury

60


Pˇríloha E

Dotazník existujících rˇešení

61

62

ˇ ˇ PRÍLOHA E. DOTAZNÍK EXISTUJÍCÍCH REŠENÍ

Pˇríloha F

Low-fidelity prototype

63

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

Recommend Documents