Vstupenkový informační systém divadla

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Vstupenkový informační systém divadla Jiří Duchek

Vedoucí práce: Ing. Martin Molhanec CSc.

Studijní program: Elektrotechnika a informatika, dobíhající, Magisterský Obor: Výpočetní technika 20. ledna 2009

iv

v

Poděkování Na tomto místě bych chtěl poděkovat všem, kteří mě podporovali při psaní této diplomové práce. Především bych chtěl poděkovat vedoucímu diplomové práce Ing. Martinu Molhancovi za jeho vstřícnost a cenné podněty. Poděkování také patří mému kolegovi a kamarádovi Jiřímu Frišaufovi za jeho rady a připomínky. V neposlední řadě bych chtěl poděkovat manželce Anně za její trpělivost.

vi

vii

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

V Praze dne 20. ledna 2009

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

viii

Abstract This diploma thesis deals with the analysis of requirements for a theatre ticket information system, its design and own implementation. In the first place it focuses on utilization of open-source or freeware tools, multiplatformity and extendibility. The resulting information system should become a base for creation of a theatre information system providing ticket sales and prepaid cards with the possibility to extend further in need to respond to future requirements.

Abstrakt Tato diplomová práce se zabývá analýzou požadavků na vstupenkový informační systém divadla, návrhem a jeho vlastní implementací. Důraz je kladen především na využití open-source nebo freeware nástrojů, multiplatformitu a rozšiřitelnost. Výsledný informační systém by měl sloužit jako základní stavební prvek informačního systému divadla zajišťující prodej vstupenek a předplatitelských legitimací, s možností rozšiřování dle budoucích požadavků.

ix

x

Obsah 1 Úvod

1

2 Použité technologie 2.1 Java EE . . . . . . . . . . . . . . . . . 2.2 Java Servlets . . . . . . . . . . . . . . 2.2.1 Java Servlet API . . . . . . . . 2.2.2 Interakce klient-server . . . . . 2.2.3 Životní cyklus servletu . . . . . 2.3 Javascript . . . . . . . . . . . . . . . . 2.4 AJAX . . . . . . . . . . . . . . . . . . 2.5 SVG . . . . . . . . . . . . . . . . . . . 2.5.1 Skriptování a animace . . . . . 2.5.2 Podpora pro SVG ve webových 2.6 XSLT a XSL-FO . . . . . . . . . . . . 2.7 Jetty . . . . . . . . . . . . . . . . . . . 2.8 ExtJS . . . . . . . . . . . . . . . . . . 2.9 PostgreSQL . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

3 3 3 4 4 5 5 6 7 7 7 8 9 9 9

3 Úvodní studie 3.1 Současný stav . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Celorepublikoví prodejci . . . . . . . . . . . . . . . 3.1.2 Samostatné systémy . . . . . . . . . . . . . . . . . 3.1.3 Proč vlastní řešení? . . . . . . . . . . . . . . . . . 3.2 Deklarace záměru . . . . . . . . . . . . . . . . . . . . . . . 3.3 Odborný článek . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Tisk vstupenek . . . . . . . . . . . . . . . . . . . . 3.3.1.1 Jehličkové tiskárny . . . . . . . . . . . . . 3.3.1.2 Laserové a inkoustové tiskárny . . . . . . 3.3.1.3 Termální nebo termotransferové tiskárny 3.4 Nefunkční požadavky . . . . . . . . . . . . . . . . . . . . . 3.5 Návrh architektury . . . . . . . . . . . . . . . . . . . . . . 3.6 Analýza rizik . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Rizika technologická . . . . . . . . . . . . . . . . . 3.6.1.1 Nedostatečné nástroje pro vývoj . . . . . 3.6.1.2 Nekompatibilita HW a SW . . . . . . . . 3.6.1.3 Výkonnost HW a SW . . . . . . . . . . . 3.6.2 Rizika procesní . . . . . . . . . . . . . . . . . . . . 3.6.2.1 Chyby v analýze . . . . . . . . . . . . . . 3.6.2.2 Odklon od požadavků . . . . . . . . . . .

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

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

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

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

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

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

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

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

11 11 11 11 12 12 12 14 15 15 15 15 16 16 17 17 17 17 18 18 18

xi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . prohlížečích . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

xii

OBSAH

3.6.3

3.6.4

3.6.2.3 Špatný odhad velikosti . . . . Rizika implementační . . . . . . . . . . 3.6.3.1 Nepochopení ovládání . . . . . 3.6.3.2 Znalosti použitých technologií 3.6.3.3 Nedostatečné testování . . . . Rizika bezpečnostní . . . . . . . . . . . 3.6.4.1 Chyba SW . . . . . . . . . . . 3.6.4.2 Chyba HW . . . . . . . . . . .

. . . . . . . .

4 Analýza řešení 4.1 Seznam aktérů . . . . . . . . . . . . . . . . . . . 4.2 Analýza případů použití . . . . . . . . . . . . . . 4.2.1 Přihlášení uživatele . . . . . . . . . . . . . 4.2.2 Autentizace uživatele . . . . . . . . . . . 4.2.3 Odhlášení uživatele . . . . . . . . . . . . . 4.2.4 Změna hesla přihlášeného uživatele . . . . 4.2.5 Správa uživatelů . . . . . . . . . . . . . . 4.2.5.1 Přidání uživatele . . . . . . . . . 4.2.5.2 Editace uživatele . . . . . . . . . 4.2.5.3 Změna hesla uživatele . . . . . . 4.2.5.4 Smazání uživatele . . . . . . . . 4.2.5.5 Seznam uživatelů . . . . . . . . 4.2.6 Vytvoření nového zákazníka . . . . . . . . 4.2.7 Vyhledání zákazníka . . . . . . . . . . . . 4.2.7.1 Smazání zákazníka . . . . . . . . 4.2.7.2 Editace zákazníka . . . . . . . . 4.2.7.3 Sloučení zákazníka . . . . . . . . 4.2.8 Seznam akcí . . . . . . . . . . . . . . . . . 4.2.8.1 Výběr sedadel . . . . . . . . . . 4.2.8.2 Detail akce . . . . . . . . . . . . 4.2.8.3 Vyhledání akce . . . . . . . . . . 4.2.9 Vytvoření nové legitimace . . . . . . . . . 4.2.9.1 Vytvoření fixního předplatného . 4.2.9.2 Vytvoření volného předplatného 4.2.10 Nákupní košík . . . . . . . . . . . . . . . 4.2.10.1 Prohlížení košíku . . . . . . . . . 4.2.10.2 Smazání košíku . . . . . . . . . . 4.2.10.3 Rezervace košíku . . . . . . . . . 4.2.10.4 Prodej košíku . . . . . . . . . . . 4.2.10.5 Vytvoření zakázky . . . . . . . . 4.2.10.6 Výběr zákazníka . . . . . . . . . 4.2.11 Seznam zakázek . . . . . . . . . . . . . . 4.2.11.1 Vyhledání zakázky . . . . . . . . 4.2.11.2 Storno zakázky . . . . . . . . . . 4.2.11.3 Editace zakázky . . . . . . . . . 4.2.11.4 Vystavení dokladu . . . . . . . . 4.3 Konceptuální datový model . . . . . . . . . . . .

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

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

. . . . . . . .

18 18 18 19 19 19 19 19

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

21 21 21 22 22 23 24 24 26 26 26 27 28 29 29 30 31 32 33 34 35 36 36 37 37 38 39 39 40 40 41 42 43 44 44 45 46 47

OBSAH

xiii

5 Návrh a Implementace 5.1 Fyzický datový model . . . . . . . . . . . 5.1.1 Databázové tabulky . . . . . . . . 5.1.2 Uložené procedury . . . . . . . . . 5.2 Popis komponent . . . . . . . . . . . . . . 5.2.1 Package cz.comnet.gemini . . . . . 5.2.2 Package cz.comnet.gemini.cronlib . 5.2.3 Package cz.comnet.gemini.guiext2 5.2.4 Package cz.comnet.gemini.modules 5.3 GUI . . . . . . . . . . . . . . . . . . . . . 5.4 Gemini Print Server . . . . . . . . . . . .

. . . . . . . . . .

49 49 51 64 66 66 67 68 68 70 71

. . . . . .

73 73 73 73 74 74 74

7 Závěr 7.1 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Budoucnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 75 75

Literatura

77

A Instalační příručka A.1 Minimální systémové požadavky A.2 Instalace podpůrných aplikací . . A.3 Instalace serveru . . . . . . . . . A.4 Instalace GPS Serveru . . . . . .

. . . .

79 79 79 79 80

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

83 83 83 84 84 85 86 86 86 87 87 88 88 88 88 89 89 90

6 Testování 6.1 Testování kódu . . . . . . . 6.1.1 white-box testování 6.1.2 black-box testování . 6.2 Testování databáze . . . . . 6.3 Testování GUI . . . . . . . 6.4 Usability testy . . . . . . .

B Uživatelská příručka B.1 Úvod . . . . . . . . . . . . B.1.1 Základní informace B.1.2 Filtry . . . . . . . B.1.3 Seznamy . . . . . . B.1.4 Menu . . . . . . . B.2 Servis systému . . . . . . B.2.1 Správa modulů . . B.2.2 Správa rolí . . . . B.2.3 SQL konzole . . . B.2.4 Správa cronu . . . B.2.5 Systémový log . . B.2.6 GPS . . . . . . . . B.2.6.1 Servery . B.2.6.2 Tiskárny B.2.6.3 Šablony . B.2.6.4 Úlohy . . B.2.6.5 Soubory .

. o . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . .

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

. . . . . .

. . . .

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

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

. . . . . . . . . .

. . . . . .

. . . .

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

xiv

OBSAH B.3 Správa systému . . . . . . . . . . . . . . . . B.3.1 Správa hledišť . . . . . . . . . . . . . B.3.2 Správa blokací . . . . . . . . . . . . B.3.3 Správa slev . . . . . . . . . . . . . . B.3.4 Správa her . . . . . . . . . . . . . . B.3.5 Správa akcí . . . . . . . . . . . . . . B.3.5.1 Nová akce . . . . . . . . . . B.3.5.2 Detail akce . . . . . . . . . B.3.5.3 Detail akce . . . . . . . . . B.3.5.4 Kopírování akce . . . . . . B.3.6 Správa předplatného - definice typů B.3.7 Správa pracovišť . . . . . . . . . . . B.3.8 Správa uživatelů . . . . . . . . . . . B.3.9 Změna hesla . . . . . . . . . . . . . B.3.10 Číselníky . . . . . . . . . . . . . . . B.4 Statistiky . . . . . . . . . . . . . . . . . . . B.5 Prodej . . . . . . . . . . . . . . . . . . . . . B.5.1 Adresář . . . . . . . . . . . . . . . . B.5.2 Košík . . . . . . . . . . . . . . . . . B.5.3 Zakázky . . . . . . . . . . . . . . . . B.5.4 Seznam akcí . . . . . . . . . . . . . . B.5.5 Rezervace . . . . . . . . . . . . . . . B.5.6 Předplatné . . . . . . . . . . . . . . B.5.7 Doklady . . . . . . . . . . . . . . . . B.5.8 Seznam vstupenek . . . . . . . . . . B.5.9 Storna vstupenek . . . . . . . . . . . B.6 GPS (aplikace) . . . . . . . . . . . . . . . . B.6.1 Konfigurační soubor . . . . . . . . .

C Obsah přiloženého CD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

90 90 91 92 92 93 93 94 95 95 96 98 98 98 98 99 100 100 101 103 105 106 107 108 108 109 109 109 111

Seznam tabulek 3.1 3.2

Porovnání jednotlivých druhů tisku . . . . . . . . . . . . . . . . . . . . . Souhrn rizik vyvíjeného systému . . . . . . . . . . . . . . . . . . . . . .

14 16

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34

Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use Use

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

22 23 24 24 25 26 26 27 27 28 29 30 30 31 32 33 34 35 36 36 37 38 38 39 40 40 41 42 43 43 44 45 45 46

5.1

Databázová tabulka: abonma . . . . . . . . . . . . . . . . . . . . . . . .

51

Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case: Case:

Přihlášení uživatele . . . . . . . . . Autentizace uživatele . . . . . . . . Odhlášení uživatele . . . . . . . . . Změna hesla přihlášeného uživatele Správa uživatelů . . . . . . . . . . Přidání uživatele . . . . . . . . . . Editace uživatele . . . . . . . . . . Změna hesla uživatele . . . . . . . Smazání uživatele . . . . . . . . . . Seznam uživatelů . . . . . . . . . . Vytvoření nového zákazníka . . . . Vyhledání zákazníka . . . . . . . . Smazání zákazníka . . . . . . . . . Editace zákazníka . . . . . . . . . . Sloučení zákazníka . . . . . . . . . Seznam akcí . . . . . . . . . . . . . Výběr sedadel . . . . . . . . . . . . Detail akce . . . . . . . . . . . . . Vyhledání akce . . . . . . . . . . . Vytvoření nové legitimace . . . . . Vytvoření fixního předplatného . . Vytvoření volného předplatného . . Nákupní košík . . . . . . . . . . . . Prohlížení košíku . . . . . . . . . . Smazání košíku . . . . . . . . . . . Rezervace košíku . . . . . . . . . . Prodej košíku . . . . . . . . . . . . Vytvoření zakázky . . . . . . . . . Výběr zákazníka . . . . . . . . . . Správa zakázek . . . . . . . . . . . Vyhledání zakázky . . . . . . . . . Storno zakázky . . . . . . . . . . . Editace zakázky . . . . . . . . . . . Vystavení dokladu . . . . . . . . .

xv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xvi

SEZNAM TABULEK 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 5.29 5.30 5.31 5.32 5.33 5.34 5.35 5.36 5.37

Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová Databázová

tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka: tabulka:

abonmatypy . . . . . abonmatypyd . . . . abonmazony . . . . . abonmazonyd . . . . abonmad . . . . . . akce . . . . . . . . . akcecenovekategorie akcedata . . . . . . . akceslevy . . . . . . akcetypy . . . . . . . akced . . . . . . . . blokace . . . . . . . blokaceuzivatele . . . doklady . . . . . . . hlediste . . . . . . . hledistesedadla . . . hledistesektory . . . hry . . . . . . . . . . hrydata . . . . . . . hrytypy . . . . . . . kontakty . . . . . . . platby . . . . . . . . pracoviste . . . . . . predstaveni . . . . . prodeje . . . . . . . rezervace . . . . . . rezervaced . . . . . . role . . . . . . . . . . roleopravneni . . . . sabonma . . . . . . . sabonmad . . . . . . slevy . . . . . . . . . sprodeje . . . . . . . uzivatele . . . . . . . vstupenky . . . . . . zakazky . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

51 52 52 52 52 53 53 54 54 54 54 55 55 55 56 56 57 57 57 57 58 58 59 59 60 60 60 61 61 61 62 62 62 63 63 64

B.1 Příklady nastavení slev . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

Seznam obrázků 3.1

Architektura systému

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

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36 4.37

Use Case: Prihlášení uživatele . . . . . . . . . . Activity Diagram: Přihlášení uživatele . . . . . Use Case: Autentizace uživatele . . . . . . . . . Use Case: Odhlášení uživatele . . . . . . . . . . Návrh GUI: Dialog přihlášení . . . . . . . . . . Use Case: Správa uživatelů . . . . . . . . . . . Activity Diagram: Přidání uživatele . . . . . . Activity Diagram: Změna hesla uživatele . . . . Návrh GUI: Změna hesla uživatele . . . . . . . Activity Diagram: Smazání uživatele . . . . . . Návrh GUI: Správa uživatelů . . . . . . . . . . Use Case: Vytvoření nového zákazníka . . . . . Activity Diagram: Vytvoření zákazníka . . . . . Use Case: Vyhledání zákazníka . . . . . . . . . Návrh GUI: Editace zákazníka . . . . . . . . . Activity Diagram: Editace zákazníka . . . . . . Návrh GUI: Vyhledání zákazníka . . . . . . . . Activity Diagram: Sloučení zákazníka . . . . . Use Case: Seznam akcí . . . . . . . . . . . . . . Návrh GUI: Seznam akcí . . . . . . . . . . . . . Activity Diagram: Výběr sedadel . . . . . . . . Návrh GUI: Výběr sedadel . . . . . . . . . . . . Use Case: Vytvoření nové legitimace . . . . . . Activity Diagram: Vytvoření nové legitimace . Use Case: Nákupní košík . . . . . . . . . . . . . Návrh GUI: Vzhled košíku . . . . . . . . . . . . Návrh GUI: Rezervace košíku . . . . . . . . . . Activity Diagram: Prodej košíku . . . . . . . . Návrh GUI: Prodej košíku . . . . . . . . . . . . Activity Diagram: Vytvoření zakázky . . . . . . Návrh GUI: Prodej košíku . . . . . . . . . . . . Use Case: Seznam zakázek . . . . . . . . . . . . Activity Diagram: Vyhledání / Seznam zakázky Activity Diagram: Editace zakázky . . . . . . . Návrh GUI: Editace zakázky . . . . . . . . . . Activity Diagram: Vystavení dokladu . . . . . . Konceptuální datový model . . . . . . . . . . . xvii

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16 22 22 23 23 24 25 25 27 27 28 28 29 29 30 31 32 32 33 33 34 35 35 36 37 38 39 40 41 41 42 42 43 44 45 46 46 47

xviii

SEZNAM OBRÁZKŮ

5.1

ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 B.19 B.20 B.21 B.22 B.23 B.24 B.25 B.26 B.27 B.28 B.29 B.30 B.31 B.32 B.33 B.34 B.35

Hlavní okno aplikace . . . . . . . . . Seznam akcí . . . . . . . . . . . . . . Menu aplikace . . . . . . . . . . . . . Dialog Editace oprávnění role . . . . Dialog Editace cron záznamu . . . . Dialog Editace tiskárny . . . . . . . Dialog Přidání nového souboru . . . Dialog Editace hlediště . . . . . . . . Dialog Přiřazení uživatelů blokace . Dialog Přiřazení typu hry . . . . . . Dialog Nastavení ceny . . . . . . . . Dialog Nastavení blokace . . . . . . Dialog Kopírování akce . . . . . . . . Dialog Nový typ předplatného . . . . Dialog Editace návštěv . . . . . . . . Dialog Editace cenové zóny . . . . . Dialog Editace uživatele . . . . . . . Volba výstupu . . . . . . . . . . . . Statistika akcí . . . . . . . . . . . . . Adresář . . . . . . . . . . . . . . . . Dialog Výběr zákazníka . . . . . . . Nákupní košík . . . . . . . . . . . . . Dialog Nové rezervace . . . . . . . . Dialog Rychlého prodeje . . . . . . . Dialog Vytvoření zakázky . . . . . . Dialog storno zakázky . . . . . . . . Dialog Editace zakázky . . . . . . . Dialog Tisk jednotlivých vstupenek . Seznam akcí . . . . . . . . . . . . . . Dialog Nový prodej/rezervace . . . . Dialog Editace rezervace . . . . . . . Dialog Výběr typu legitimace . . . . Dialog Výběr sedadla pro legitimaci Storna vstupenek . . . . . . . . . . . GPS - stavové okno . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

50 84 85 85 86 87 89 90 91 91 92 94 95 95 96 97 97 98 99 99 100 100 101 101 102 103 103 104 104 105 106 107 107 108 109 110

Kapitola 1

Úvod Cílem této diplomové práce je návrh a implementace vstupenkového informačního systému divadla pro společnost ComNet, s.r.o. Navrhovaný systém musí podporovat agendu divadla spojenou s prodejem vstupenek a předplatitelských legitimací, konkrétně správu zákazníků, představení, hledišť, slev a rezervací. Systém musí umožňovat přehledné výpisy a statistiky pro vedení divadla. Důležitou roli v návrhu je požadavek na multiplatformitu systému, a to jak na straně serveru, tak na straně klientských stanic. Dalším neméně důležitým požadavkem je využití vhodných freeware nebo open source technologií. Všechny části projektu jsou pečlivě dokumentovány v souladu se zvyklostmi softwarového inženýrství. V následující kapitole se nachází stručné seznámení s technologiemi, jako např. Java EE, Java Servlets, JavaScript, AJAX a nástroji, jako např. Jetty, Ext JS a PostgreSQL, které byly v rámci implementace použity. V třetí kapitole nalezneme úvodní studii obsahující seznámení se současným stavem, deklaraci záměru, odborný článek, dále pak katalog požadavků, návrh architektury a analýzu rizik. V této kapitole se též seznámíme s různými technologiemi tisku vstupenek. Ve čtvrté kapitole je provedena analýza projektu. Tato část obsahuje přehled aktérů systému, ale především konceptuální datový model a analýzu případů použití. Jednotlivé případy jsou modelovány pomocí Use Case tabulek, Activity diagramů a jsou zde načrtnuty návrhy grafického uživatelského rozhranní. Implementaci je věnována pátá kapitola, zaměřena je především na seznámení s datovým modelem, jednotlivými tabulkami a uloženými procedurami, které tvoří páteř systému. V neposlední řadě se zde blíže seznámíme s architekturou a jsou zde rozebrány nejzajímavější partie systému. Šestá kapitola je věnována testování a sedmou kapitolou, závěrem, je tato práce výhledem do budoucnosti systému ukončena. Nedílnou součástí práce je instalační a uživatelská příručka, které tvoří přílohy A a B.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Použité technologie Tato podkapitola má za úkol seznámení s nejdůležitějšími technologiemi, které jsou pro řešený úkol použity.

2.1

Java EE

Java Platform, Enterprise Edition (neboli Java EE, dříve označovaná jako Java 2 Enterprise Edition nebo J2EE ) je součást platformy Java od firmy SUN určená pro vývoj a provoz podnikových aplikací a informačních systémů. Základem pro platformu Java EE je platforma Java SE, nad ní jsou definovány součásti tvořící Java EE. Součásti platformy Java EE: • vývoj webových aplikací - Java Servlets, Java Server Pages (JSP) • vývoj sdílené business logiky - Enterprise Java Beans (EJB), Spring • přístup k legacy systémům - Java Connector Architecture (JCA), Hibernate • přístup ke zprávovému middleware - Java Messaging Services (JMS) • podpora technologií Web Services Aplikace pro platformu Java EE jsou vyvíjeny na základě API a dalších fragmentů definovaných v jednotlivých specifikacích. Běhovým prostředím pro tyto aplikace je poté tzv. Aplikační Server. Pro účely této diplomové práce využijeme minimální součásti Java EE, Java Servlets. Z tohoto důvodu nebudeme využívat služeb plnohodnotného Java aplikačního serveru

2.2

Java Servlets

Jak jsem již výše uvedl, servlety jsou součástí platformy Java EE. Jedná se o programové komponenty napsané v Javě a běžící na straně serveru, tzn. že vyžadují „ javaenabled-serverÿ a JVM1 . Se servlety se setkáme též např. při technologii JSP2 . Servlety 1 2

Java Virtual Machine Java Server Pages

3

4

KAPITOLA 2. POUŽITÉ TECHNOLOGIE

jsou načítané a spouštěné pomocí JVM na příslušném aplikačním serveru. Podle specifikace se jedná o nevizuální komponenty, což však neznamená, že servlety nemohou „generovatÿ uživatelské rozhranní. Ve skutečnosti jsou právě ve velkém používány servlety pracující nad internetovým protokolem HTTP. Odpovědí těchto servletů je potom převážně HTML kód. Servlety implementují princip požadavek-odpověď, což je typický příklad architektury klient-server. Java Servlet API definuje standardní rozhranní pro obsluhu těchto požadavků a odpovědí mezi klientem a serverem. Následující obrázek ilustruje procesy mezi klientem a serverem. Servlety můžeme přirovnat k CGI3 skriptům v tom, že pomocí servletu můžeme též vytvářet dynamický obsah. Servlety mají řadu nesporných výhod: • Portabilita a platformová nezávislost - díky založenosti na Javě • Perzistence a výkonnost - servlet je zkompilovaný a nahraný do paměti pouze jednou při inicializaci, tím servlet méně zatěžuje systémové zdroje • Založenost na Javě - objektovost, modularita, bezpečnost

2.2.1

Java Servlet API

Java Servlet API je množinou Java tříd definujících rozhranní mezi klientem a serverem. Servlet API není standardní součásti Java frameworku, ale je k dipozici buď jako součást Java EE nebo jako samostatný balíček. API sestává ze základního balíčku javax.servlet obsahuje abstraktní třídy a rozhranní na tvorbu všeobecných servletů (např. pro protokol HTTP,FTP, apod.). Balík javax.servlet.http rozšiřuje funkcionalitu základního balíku a přidává podporu protokolu HTTP. V našem případě potřebujeme servlet pracující s protokolem HTTP a budeme proto využívat rozšiřující balík javax.servlet.http, potažmo specializovanou třídu HttpServlet. Tato třída poskytuje další metody na zpracování HTTP požadavků, především doGet() a doPost() na zpracování požadavků typu GET a POST.

2.2.2

Interakce klient-server

Klient posílající požadavek aplikaci založené na servletech nekomunikuje přímo s nimi, ale s příslušným serverem. Server poté předá požadavek servletu pomocí Java Servlet API. Úlohou serveru je řídit spouštění a inicializaci servletů, jejich ukončení a likvidace z paměti. Standardně se v paměti nachází pouze jedna instance servletu, v případě příchodu několika požadavku najednou, server vytvoří po každý požadavek samostatné vlákno - servlety jsou multithreadové4 . Za veškerou výše uvedenou funkcionalitu je zodpovědný server. Následující obrázek ilustruje základní interakci mezi klientem a serverem. 3 Common Gateway Interface - standardní protokol pro program spouštěný na straně informačního serveru, především WWW serveru. 4 Existují též servlety singlethreadové, díky implementaci SingleThreadModel - pro více informací odkazuji na literaturu Java EE[13]

2.3. JAVASCRIPT

2.2.3

5

Životní cyklus servletu

Životní cyklus servletu je zajištěn prostřednictvím metod init(), service(), respektive doGet()/doPost() a destroy(). Nyní se podíváme na jednotlivé metody: • Inicializace servletu - init() Servlet je spouštěn na nahráván do paměti dynamicky. Záleží na konfiguraci serveru, zda bude servlet načten při startu serveru nebo až při prvním požadavku na servlet. Vždy ještě před prvním požadavkem je volána metoda init(). Zde je vhodné např. vytvořit spojení s databází nebo inicializovat proměnné, v opačném případě není nutné metodu implementovat a automaticky je volána inicializace nadřazené třídy. • Obsluha požadavků - doGet(), doPost() Každý požadavek, resp. odpověď je reprezentován příslušným objektem třídy ServletRequest, resp. ServletResponse z příslušného Java Servlet API. Pro náš případ HTTP Servletu budeme uvažovat objekty HttpServletRequest, resp. HttpServletResponse. Musím zde ještě zmínit metodu service(). Jak již bylo zmíněno výše, při zavolání servletu je vytvořeno vlákno a díky tomu může servlet obsloužit více požadavků najednou. Při vytvoření je právě volána metoda service(), ta však nedělá nic jiného, než zkontroluje typ požadavku (GET, POST, PUT, . . .) a podle toho zavolá příslušnou metodu. V běžné praxi a v naší aplikaci se střetneme především s metodami doGet() a doPost. Objekt HttpServletRequest obsahuje všechny informace od klienta, včetně informací o prostředí (IP adresa, verze prohlížeče, podporované MIME5 , atd.) a všech vstupních dat. Tento objekt obsahuje také metody vhodné pro přístup k jednotlivým hodnotám, např. getParameter(), getAttribute(), getRequestURL() a další. Objekt HttpServletResponse je dynamicky vytvořená odpověď klientovi. Odpověď servletu může být HTML stránka, ale také např. XML dokument, obrázek, atd. Odpovědí může být také přesměrování na jiné URL, servlet. • Odstranění instance servletu - destroy() Tato metoda je volána před odstraněním servletu z paměti serveru. Zde je vhodné provést vlastní úklid, např. uzavření databázových spojení). Stejně jako metodu init() jí není nutné implementovat (pokud není třeba).

2.3

Javascript

Javascript je multiplatformní, objektově orientovaný, slabě typový a prototypově založený skriptovací jazyk, jehož autorem je Brendan Eich z tehdejší společnosti Netscape. Javascript byl ovlivněn mnoha jazyky a byl navržen tak, aby byl podobný Javě. Navzdory názvu však Javascript s Javou v podstatě nesouvisí. Program v JavaScriptu se obvykle spouští až po stažení WWW stránky ze serveru (tzv. na straně klienta), na rozdíl od ostatních jiných interpretovaných programovacích jazyků (např. PHP a ASP), které se spouštějí na straně serveru ještě před stažením z Internetu. Z toho plynou jistá 5

MIME Type - Internet media type - identifikace formátu dat, definováno dle RFC 2046

6


bezpečností omezení, JavaScript např. nemůže pracovat se soubory, aby tím neohrozil soukromí uživatele. Primární použití JavaScriptu je napsat funkce, které jsou zahrnuty v HTML stránce a zajišťují interakci s DOM6 . V této práci bude Javascript využíván pro zajištění logiky uživatelského rozhranní a pro získávání a odesílání dat aplikačnímu serveru (AJAX).

2.4

AJAX

AJAX (Asynchronous JavaScript and XML) je obecné označení pro technologie vývoje interaktivních webových aplikací, které mění obsah svých stránek bez nutnosti jejich znovunačítání. Na rozdíl od klasických webových aplikací poskytují uživatelsky příjemnější prostředí, ale vyžadují použití moderních webových prohlížečů. AJAX ve skutečnosti není konkrétní jednotlivá technologie, ale pojem označující použití několika technologií dohromady s určitým cílem. Tyto aplikace jsou vyvíjeny s využitím technologií: • HTML (nebo XHTML) a CSS pro prezentaci informací • DOM a JavaScript pro zobrazování a dynamické změny prezentovaných informací • XMLHttpRequest pro asynchronní výměnu dat s webovým serverem (typicky je užíván formát XML, ale je možné použít libovolný jiný formát včetně HTML, prostého textu, JSON či EBML). V našem případě budeme používat lehce upravenou kombinaci formátu prostého textu a JSON

Výhody • AJAX urychluje uživateli práci, v tom je jeho hlavní výhoda. Nemusí se pokaždé znovu nahrávat nová stránka. Toto chování je daleko blíže tomu, co zná uživatel z klasických desktopových aplikací – a známé pravidlo použitelnosti je držet se toho, co už uživatel zná. • AJAX šetří datové přenosy. U klasické webové aplikace se s každým požadavkem musí uživateli posílat celý kód stránky, v němž je nového a důležitého po málu. Naopak s AJAXem se posílá jenom to důležité.

Nevýhody • AJAX znemožňuje použití tlačítka Zpět v prohlížeči (protože to se používá jen pro statické stránky). Toto se dá bez váhání označit za největší problém AJAXu. Uživatelé jsou na tlačítko Zpět zvyklí a očekávají od něj určitou funkci. AJAX jim ale v lepším případě vůbec neumožní ho použít, v tom horším použít půjde, ale jeho chování bude naprosto neočekávané – vrátí uživatele na předcházející stránku, nevrátí aplikaci do předcházejícího stavu (a pravděpodobně se jeho stisknutím ztratí uživateli práce, kterou na stránce pomocí AJAXu udělal). 6

Document Object Model – objektový model dokumentu je objektově orientovaná reprezentace XML nebo HTML dokumentu na stránce.

2.5. SVG

7

• Při změnách na stránce pomocí AJAXu se nemění URL v adresním řádku prohlížeče. Proto není možné takto modifikovanou stránku poslat e-mailem nebo uložit do záložek. Tento problém řeší AJAXové aplikace tak, že se za URL dosazují identifikátory začínající na # (odkaz dovnitř stránky). Při opětovném vyvolání takového URL ho JavaScript zjistí a uvede stránku do příslušného stavu (tím se dá vyřešit i problém s tlačítkem Zpět). Problém je, že na cílovém počítači musí být dostupný ten JavaScript. • Všechno s AJAXem nejde. Nesmíme zapomínat, že AJAX je stále pouze nadstavbou nad stávajícími webovými technologiemi, která se snaží překonat některá jejich omezení. A především protokol HTTP vůbec není vhodný pro aplikace spolupracující intenzivně se serverem – problémem je, že se při každém požadavku musí navázat spojení se serverem, které se po jeho vyřízení ukončí. To aplikaci zpomaluje.

2.5

SVG

SVG (Scalable Vector Graphics) je značkovací jazyk a formát souboru, který popisuje dvojrozměrnou vektorovou grafiku pomocí XML. Formát SVG by se měl v budoucnu stát základním otevřeným formátem pro vektorovou grafiku na Internetu. Zatímco pro rastrovou grafiku je na Internetu formátů dostatek (např. GIF, PNG a JPEG), otevřený vektorový formát zatím na Internetu chyběl. SVG umožňuje tři typy grafických objektů: • Vektorová grafika • Rastrová grafika • Text SVG je v projektu využíváno pro zobrazení plánku hlediště a zajištění výběru sedadel.

2.5.1

Skriptování a animace

SVG kresby mohou být dynamické a interaktivní. Časově založená modifikace prvků může být popsána v jazyce SMIL7 nebo ve skriptovacím jazyce (např. Javascript). Je poskytován bohatý soubor událostí, jako např. onmouseover nebo onclick, které lze přiřadit jakémukoliv SVG grafickému objektu.

2.5.2

Podpora pro SVG ve webových prohlížečích

Většina současných moderních prohlížečů má již podporu pro SVG integrovánu přímo v jádře. 7

Synchronized Multimedia Integration Language - značkovací jazyk napsaný v XML, je určen pro značkování načasování, animace, vizuální přechody

8

KAPITOLA 2. POUŽITÉ TECHNOLOGIE • Prohlížeče založené na jádře Gecko (Firefox, Flock, Netscape, Camino) - nativní neúplná podpora SVG 1.1, nové Gecko 1.9 výrazně vylepšuje podporu SVG 1.1, nicméně stále není plná. • Prohlížeče založené na jádře WebKit (Safari, Chrome) - nativní neúplná podpora SVG 1.1 • Opera - od verze 9.5 nativní plná podpora SVG 1.1 • Internet Explorer - není nativní podpora - nutný plugin od Adobe8 .

2.6

XSLT a XSL-FO

Základní myšlenkou, na které staví většina značkovacích jazyků včetně XML a SGML, je důsledné oddělení obsahu dokumentu od jeho vzhledu. Značky použité v XML dokumentu vyznačují význam jeho jednotlivých částí – říkají např. toto je jméno, toto je příjmení, atd. O tom, jak se konkrétní údaj zobrazí na obrazovce nebo vytiskne na tiskárně, samotný jazyk XML nic neříká. Můžeme si však odděleně vytvořit definici vzhledu jednotlivých elementů, které se říká styl. A pro popis stylu se právě stará např. XSL9 . S jeho pomocí je pak zobrazení dokumentu velice snadné, stačí mít k dispozici aplikaci, která umí číst XML dokumenty a rozumí použitému stylovému jazyku. Postupně se ukázalo, že XSL má sloužit ke dvěma poměrně odlišným věcem – ke transformaci XML dokumentů a k definici vzhledu jejich formátování. První část XSL slouží k transformaci dokumentů, pro kterou se používá název XSLT (XSL Transformations). Pomocí XSLT lze vytvářet styly, které definují, jak se XML dokumenty mají převádět do formátu HTML, do XML dokumentů s jinou strukturou nebo do obyčejných textových souborů. Zejména možnost konverze do HTML je dnes hojně využívána, protože většina prohlížečů si zatím se samotnými XML dokumenty neporadí. Druhé části XSL, která slouží k přesnému popisu vzhledu dokumentu, se často říká XSL FO (formátovací objekty), někdy jen zkráceně XSL. K dispozici máme vše, co známe z CSS10 , navíc lze přesně určit layout stránky – včetně sazby do více sloupců, hlaviček, patiček apod. Pokud chceme použít formátovací objekty pro zformátování našeho dokumentu, musíme si vytvořit odpovídající styl. Ten se pomocí XSLT aplikuje na zdrojový XML dokument – dostaneme tedy XML dokument, který se bude skládat z jednotlivých formátovacích objektů. Tento dokument pak umí interpretovat procesor FO, který z něj vytvoří třeba PDF soubor nebo výsledek zobrazí na obrazovce. Některé programy oba dva kroky provádí automaticky najednou a celý proces pak může uživateli připadat jednodušší. 8

http://www.adobe.com/svg eXtensible Stylesheet Language 10 Cascading Style Sheets - jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. 9

2.7. JETTY

2.7

9

Jetty

Jetty[14] je open-source, standardní a plnohodnotný web server a servlet container, který je napsán kompletně v jazyce JAVA. Server je šířen pod Apache 2.0 licencí11 a je zdarma pro komerční použití. Díky tomu, že ne napsán v Javě, je přenositelný a multiplatformní. Jetty může být použit v různých konfiguracích: • tradiční „stand-aloneÿ server pro poskytování dynamického a statiského obsahu • server pro poskytování dynamického obsahu za dedikovaným HTTP serverem (např. Apache s mod-proxy) • vložená „embeddedÿ komponenta JAVA aplikace Výhody Jetty jsou především: • Velikost - server je malý a nenáročný, jednoduše se distribuuje. • Konfigurovatelnost - jednoduchá konfigurace přes XML konfigurační soubor • Jednoduchost - server není aplikačním serverem, jedná se pouze o servlet container (jinou vlastnost aplikací GEMINI není využíváno) • Výkonnost - dobrá škálovatelnost, minimum závislostí Jetty je v implementaci využíváno jako servlet container pro aplikaci.

2.8

ExtJS

Ext[10] je JavaScriptová knihovna pro tvorbu interaktivních Webových aplikací používajících techniky AJAX, DHTML12 a DOM13 skriptování. Ext je postaven na přídavná rozšiřující knihovna YUI14 . Ext je šířen pod LGPL 3.0 licencí, nicméně v současné době probíhá bouřlivá diskuse o formě licence (pro komerční použití). Ext poskytuje velké množství ovládacích prvků „widgetsÿ (např. combobox, listbox, toolbar, tab panels, grid control, a další) a podpor po vývoj aplikací (modální dialogy, aj.).

2.9

PostgreSQL

PostgreSQL[16] je relační databázový server s otevřeným zdorjovým kódem. Server je šířen pod BSD licencí15 a je k dispozici zdarma pro komerční použití16 . Server je 11

http://www.mortbay.org/jetty/LICENSE.txt Dynamic HTML 13 Document Object Model 14 Yahoo! UI Library - http://developer.yahoo.com/yui/ 15 http://www.postgresql.org/about/licence 16 Oproti např. MySQL, která je zdarma pouze pro nekomerční použití 12

10


provozovatelný ne většině rozšířených operačních systémů, především na Windows a Linuxu. Server splňuje podmínky ACID17 , plně podporuje cizí klíče, operace JOIN, pohledy, triggery a uložené procedury. Obsahuje většinu SQL92 a SQL99 datových typů. Uložené procedury mohou být napsány v několika jazycích (např. Python, Perl nebo PL/pgSQL - jazyk podobný PL/SQL firmy Oracle)

17

ACID je obecně uznávaný seznam požadavků na bezpečný transakční systém (Atomic, Consistent, Isolated, Durable)

Kapitola 3

Úvodní studie 3.1

Současný stav

V současné době je možné nabídku vstupenkových systémů rozdělit na dva druhy: vstupenkové systémy celorepublikových prodejců (TicketPortal1 , Ticket-Art2 , TicketPro3 , Ticket-Stream4 ) a samostatné vstupenkové systémy (Colosseum 3000, Pegas).

3.1.1

Celorepublikoví prodejci

Výhodou těchto prodejců je velké množství zavedených prodejních míst, možnost internetového prodeje. Většina prodejců poskytuje svůj vlastní prodejní systém divadlům, nicméně velkou nevýhodou je, že se jedná o systémy obecné, aby vyhovovaly co největšímu počtu zákazníků, tudíž obsahují velké množství funkcí, které divadlo nevyužije a nemusí obsahovat všechny funkce, které divadlo potřebuje. Následné rozšíření systému prodejce je ve většině případů nemožné a divadlo je nuceno se systému přizpůsobit nebo zvolit systém jiný. Další nevýhodou je i to, že některé systémy vyžadují stálé připojení k internetu, a to z důvodu, že je systém provozován na serverech prodejce. Divadlo má tudíž přístup k vlastním datům pouze přes internet a v případě výpadku připojení jsou odstřiženi od systému a veškerý prodej přes systém není možný.

3.1.2

Samostatné systémy

Dostupnost samostatných vstupenkových systému na trhu není příliš veliká. Vyskytuje se zde v podstatě jediný moderní produkt společnosti Perfect-System, s.r.o. nazvaný Colosseum 30005 . Tento systém je možné provozovat samostatně v divadle, obsahuje navíc možnost rezervací vstupenek přes internet. Systém Colosseum je tvořen ve skutečnosti několika verzemi (verze pro stadiony, kulturní památky, muzea, divadla), seskupením jednotlivých systémů je možné vytvořit vlastní prodejní síť. Nevýhodou tohoto systému je jeho finanční náročnost, uzavřenost a provoz pouze pod operačním systémem Windows. Pro práci se systémem musí být nainstalován potřebný software. 1

http://www.ticketportal.cz http://vstupenky.ticket-art.cz 3 http://www.ticketpro.cz 4 http://www.ticketstream.cz 5 http://www.perfect-system.cz 2

11

12

KAPITOLA 3. ÚVODNÍ STUDIE

Mezi další samostatné vstupenkové systémy můžeme zahrnout vstupenkový systém Pegas, spravovaný společností SoftPro, s.r.o. . Tento produkt je již velmi zastaralý (je provozován pod MS DOS) a nepodporuje moderní způsoby rezervací a prodeje vstupenek před internet. Ve své době se ale jednalo o nejpopulárnější systém pro prodej vstupenek v divadlech.

3.1.3

Proč vlastní řešení?

Vlastní řešení bylo zvoleno především z důvodu poskytnout divadlům konkurenční produkt systému Colosseum 3000 na otevřené architektuře, systém který je dostupný odkudkoliv pouze pomocí webového prohlížeče. Další motivací je navrhnout produkt, který bude plně otevřený, který je možný propojit se vstupenkovými systémy celorepublikových prodejců. V případě dohody a propojení by mohl vzniknout produkt, který spojuje výhody samostatného řešení s výhodami prodeje prostřednictvím prodejců. Divadla by mohla pomocí systému nastavit parametry přístupu těchto prodejců, následný prodej by již probíhal plně transparentně. Základem je ale navržení kvalitního jádra systému, které by mohlo být následně pomocí modulů rozšiřováno. Na systém bude navazovat projekt internetového prodeje a rezervace vstupenek pod názvem WebTicket. Tento systém je paralelně vyvíjen ve společnosti ComNet, s.r.o a bude plně propojen s navrhovaným systémem. Systém WebTicket není součástí této práce.

3.2

Deklarace záměru

Úkolem diplomové práce je návrh a implementace vstupenkového systému (pracovní název GEMINI 2.0 ) pro firmu ComNet, s.r.o. Tato firma se od roku 2004 zabývá vývojem zakázkového software, především pro kulturní zařízení. Firma již v současné době provozuje vlastní vstupenkový systém, který však již nevyhovuje dnešním požadavkům. Cílem je tedy vytvoření nového návrhu za využití moderních technologií s co největším důrazem na rozšiřitelnost a variabilitu systému. Předpokládané nasazení je divadlech do střední velikosti (tzn. počet sedadel cca do 1000). Vstupenkový systém musí podporovat prodej vstupenek a předplatitelských legitimací, včetně agendy spojené s těmito činnostmi, tj. správa zákazníků, představení, hledišť, slev a rezervací. Systém by měl podporovat přehledné a konfigurovatelné výpisy a statistiky pro vedení divadla. Důležitým požadavkem je multiplatformita systému, a to nejen na klientské straně, ale i na straně serveru.

3.3

Odborný článek

Základním úkolem systému „GEMINIÿ je zajištění distribuce vstupenek a předplatitelských legitimací na libovolné množství akcí pořádaných nebo zprostředkovaných majitelem systému v libovolném množství hledišť a následné statistické a účetní vyhodnocení prodeje. Před začátkem práce se musí každý uživatel systému přihlásit. Každý uživatel se přihlašuje jménem a heslem, přístup k jednotlivým částem systému může být omezen

3.3. ODBORNÝ ČLÁNEK

13

podle potřeb oprávněními implementovanými v systému. Každému uživateli je přiřazena uživatelská role v systému, která seskupuje jednotlivá omezení a umožňuje uživatele rozřadit podle pravomocí. V základu je možné rozlišit Servisní přístup, Administrátora, Prodejce vstupenek, Účetní, Externí prodejce. Zákazníci jsou zařazování do databáze Zákazníků, ke každému zákazníkovi lze uvést kontaktní a fakturační údaje. Zákazníky je možné roztřídit do cenových kategorií a tím např. poskytovat slevu věrným zákazníkům. V systému je možné definovat libovolné množství hledišť, ve kterých jsou akce konány. V základu je možné rozlišovat dva druhy hledišť podle číslování sedadel. Sedadla v hledišti mohou být číslována, tzn. je jim přiřazena např. sektor, řada, číslo (hlediště „adresníÿ), nebo nečíslována, kde zákazníci si mohou sednout kamkoliv, podle toho, jak přicházejí do hlediště, pouze podle cenové kategorie (hlediště „neadresníÿ). Rozmístění adresních sedadel je pevně definováno a nelze je měnit. Jednotlivá sedadla mohou uživatelé libovolně obarvovat. Přístup na jednotlivá sedadla může být omezen blokacemi. Blokace slouží pro vyhrazení sedadel vybraným uživatelům. U blokace je možné nastavit její platnost, po vypršení platnosti je tato zrušena a sedadla jsou uvolněna ostatním uživatelům. Každé sedadlo může mít libovolně definovanou cenu. Výsledná cena může být ovlivněna uplatněním některé se slev. V systému je možné definovat libovolné množství slev, které lze uplatnit. Slevy jsou striktně pojmenovány a jejich použití lze omezit. Definovat lze slevu buď jako procentuální hodnota ceny výchozí nebo fixní částkou, příp. kombinací obou variant. Pro výpočet slevy je použita jednoduchá lineární rovnice: cenaf inal = k ∗ cena + q . Z rovnice patrné, že slevou je možné vstupenku též zdražit. Každá akce konaná v systému se skládá z titulu (v systému veden jako hra) a představení, kde je definován čas konání. Systém umožňuje „přesunÿ představení na jiný termín nebo změnu titulu (např. z důvodu nemoci). V obou případech je však zajištěna konzistence účetních dokladů. Akce je možné třídit podle libovolně konfigurovatelných kritérií (např. muzikál, balet, atd.) a je možné k nim přiřadit libovolné množství doplňujících informací (např. délka konání, režie, atd.). V každé akci je možné libovolně měnit cenu sedadel, blokace, lze selektivně povolit slevy a nastavit procentuální hodnoty slev pro cenové kategorie zákazníků. Pro jednodušší nasazování akcí systém podporuje kopírování akcí, což je duplikace již vytvořené akce s možností dodatečných úprav parametrů. Vstupenky mohou uživatelé rezervovat, kdy po nastaveném datu vypršení jsou místa uvolněny zpět do prodeje. Dále je možné vstupenky prodat v hotovosti, platební kartou, příp. jinou formou nebo na fakturu. Vstupenky je možné též stornovat, a to buď jednotlivě nebo hromadně (např. celou objednávku). Při prodeji předplatitelských legitimací jsou rozlišovány dva druhy, fixní předplatné a předplatitelské kupóny. Fixní předplatné je chápáno jako předplacení konkrétního místa v hledišti na předem definovaný počet akcí, tyto akce je možné dodatečně upravovat. Z toho vyplývá, že fixní předplatné lze aplikovat pouze na akce konané v jednom hledišti (navíc adresním). Předplatitelské kupóny je předplatné obsahující sadu kupónů, které zákazníci směňují za vstupenky. Tyto kupóny jsou považovány za ceninu a mají nominální hodnotu na sobě uvedenou. V systému je u tohoto předplatného definovatelná sleva oproti hodnotě nominální.

14


Pro potřeby účetnictví je v systému implementována jednoduchá kniha faktur a pokladní kniha. Faktury lze stornovat buď celé nebo po částech. Pro potřeby statistického sledování a účetnictví je v systému implementována sada statistik. Tato sada obsahuje především statistiku akcí, kde je sledována návštěvnost a tržebnost, pokladní a prodejní uzávěrky a potřebné účetní statistiky, které musí být v souladu s účetními normami. Pro tisk vstupenek jsou využívány rozmanité druhy tiskáren a vstupenek. Podrobnější seznámení s jednotlivými tiskovými technologiemi je obsahem následující podkapitoly. Tiskový subsystém musí umožňovat tisk textu různých formátů a řezů písma, text otáčet, tisknout grafiku (loga) a čárové kódy. Systém musí být implementován tak, aby byla zajištěna interoperabilita s případnými systémy třetích stran.

3.3.1

Tisk vstupenek

Dle použité technologie dotisku vstupenky při jejím prodeji rozlišujeme tři základní technologie tisku, vstupenky pro termální a termotransferové tiskárny, vstupenky pro jehličkové tiskárny a vstupenky pro laserové a inkoustové tiskárny. Obecně vzhledem k ceně a rychlosti tisku, což jsou s ohledem k dané aplikaci jedny z nejdůležitějších vlastností, není doporučován tisk barevný. Tabulka 3.1: Porovnání jednotlivých druhů tisku výhody nevýhody termální tisk rychlost tisku vyšší cena výroby vstupenek možnost tisku grafiky vyšší cena tiskáren tisk čárového kódu jednoduchá obsluha slušná kvalita tisku kvalita, rozměry vstupenky nízké provozní náklady spolehlivost termotransfer rychlost tisku vyšší cena výroby vstupenek možnost tisku grafiky složitější obsluha tisk čárového kódu vyšší provozní náklady jednoduchá obsluha vyšší cena tiskáren slušná kvalita tisku kvalita, rozměry vstupenky laser levná výroba vstupenek omezená velikost vstupenek možnost tisku grafiky složitější obsluha tisk čárového kódu nízké provozní náklady levné tiskárny jehličkový tisk levná výroba vstupenek nelze tisknout grafiku jednoduchá obsluha nelze tisknout čárový kód nízké provozní náklady kvalita, rozměry vstupenek spolehlivost relativně pomalý tisk

3.4. NEFUNKČNÍ POŽADAVKY 3.3.1.1

15

Jehličkové tiskárny

Dotisk vstupenek jehličkovými tiskárnami je nejlevnější technologie tisku vzhledem k provozním nákladům. Vstupenky jsou nejčastěji dodávány ve formě „nekonečnéhoÿ pásu papíru, jsou vyrobeny na běžném offsetovém papíře o gramáži 80-120 g. Délka vstupenek může být v rozsahu 100-210 mm, výška je z technologických důvodů omezena na 2”, 3” nebo 4”6 . Lze využít i kusové vstupenky, je ale nutné použít speciální tiskárnu, která dotisk kusových vstupenek umožní. Nevýhodou této technologie je nemožnost tisku grafiky - je možné tisknout pouze text. 3.3.1.2

Laserové a inkoustové tiskárny

Dotisk vstupenek na laserových a inkoustových tiskárnách je levný, relativně rychlý a především kvalitní. Doporučovány jsou především tiskárny laserové (trvanlivost a stálost tisku), tiskárny inkoustové jsou uvedeny jako alternativa, avšak z pohledu systému jsou obě technologie rovnocenné. Vstupenky jsou dodávány buď v jednotlivých kusech nebo v archu A4 po pěti nebo čtyřech kusech. Při použití jednotlivých kusů musí být tiskárna schopná potisku vstupenky menšího rozměru. Při použití archů A4 se tyto zakládají do tiskárny jako běžný kancelářský papír. Po prodeji, například dvou vstupenek, se tyto potištěné oddělí od zbylých nepotištěných. Vstupenky se předají zákazníkovi a zbytek archu lze opět založit do tiskárny k dotisku při příštím prodeji. Problém s tímto druhem vstupenek nastává, pokud v tiskárně zbude jedna (poslední) vstupenka z archu, tu se totiž již nepodaří potisknout. 3.3.1.3

Termální nebo termotransferové tiskárny

Dotisk vstupenek na termálních nebo termotransferových tiskárnách je vhodný zejména z důvodu rychlosti a kvality tisku. Tyto tiskárny jsou povětšinou robustní, průmyslová zařízení, která jsou odolná vůči vnějším vlivům. Zařízení vynikají bezporuchovostí a jednoduchou obsluhou. Vstupenky jsou dodávány navinuté na papírovém kotoučku, případně ve formě pásu vstupenek, tzv. „skládaného leporelaÿ. Papír, tvar a rozměr vstupenky lze uzpůsobit potřebám a požadavkům zákazníka. Termální tiskárny využívají tepelný tisk přímo na vstupenky, tyto proto musí být z termocitlivého papíru. Nevýhodou jsou vysoké výrobní náklady vstupenek a malá stabilita tisku7 . Tuto nevýhodu řeší tisk termotransferový, což je vlastně tisk sublimační. Princip je stejný jako u přímého termálního tisku, jen je mezi hlavou a papírem speciální termotransferová fólie, ze které se barva teplem přenese na potiskované medium, kterým může být běžný papír.

3.4

Nefunkční požadavky

Do nefunkčních požadavků zahrnujeme požadavky, které přímo nesouvisí s funkčností systému, ale na návrh systému mají nezanedbatelný vliv. 6 7

Výška je uváděna v palcích - omezeno pevnou výškou řádky tiskárny Vysoká citlivost na teplo a světlo

16

KAPITOLA 3. ÚVODNÍ STUDIE • Systém bude multiplatformní (provozovatelný na OS Windows a Linux) • Systém bude přístupný přes webový prohlížeč (není vyžadována instalace dodatečného software) • Systém bude lehce rozšiřitelný o další moduly

3.5

Návrh architektury

Systém je postaven na třívrstvé architektuře klient-server.

WWW prohlížeč RPCServlet PostgreSQL

JDBC

Gemini Print Server JSServlet Klient

Database Server GPSServlet

Gemini Print Server

Jetty Application Server

Klient

Obrázek 3.1: Architektura systému

1. Databázovou vrstvu zajišťuje databázový server PostgreSQL 2. Aplikační vrstvu tvoří Jetty jako servlet container s Java Servlety. Servlety jsou dále rozděleny na JS Servlety zajišťující podporu pro uživatelské rozhranní systému (GUI), RPC Servlety zajišťující výkonné funkce systému a GPS Servlet zajišťující podporu tisku. 3. Prezentační vrstvu zajišťuje webový prohlížeč nebo Gemini Print Server, což je speciální utilita zajišťující tisk na klientských stanicích

3.6

Analýza rizik

Každý projekt v průběhu vývoje s sebou přináší určitá rizika. U projektů softwarových se především jedná o chybné fungování aplikace, nedodržování termínů a nepřijetí softwarového díla samotnými uživateli. Při podrobném zkoumání rizik narazíme na další rizika, která je možno rozdělit do několika skupin. V následující tabulce jsou uvedena významná rizika vyvíjeného informačního systému. Tabulka 3.2: Souhrn rizik vyvíjeného systému Riziko Nedostatečné nástroje pro vývoj Nekompatibilita HW a SW

Kategorie Technologické Technologické

Odhad 10 % 10 %

Dopad Marginální Zanedbatelný

3.6. ANALÝZA RIZIK Riziko Výkonnost HW a SW Chyby v analýze Odklon od požadavků Špatný odhad velikosti Nepochopení ovládání Znalosti použitých technologií Nedostatečné testování Chyba HW Chyba SW

3.6.1 3.6.1.1

17 Kategorie Technologické Procesní Procesní Procesní Implementační Implementační Implementační Bezpečnostní Bezpečnostní

Odhad 20 % 20 % 10 % 30 % 20 % 50 % 40 % 10 % 20 %

Dopad Marginální Kritický Marginální Kritický Kritický Kritický Kritický Katastrofický Kritický

Rizika technologická Nedostatečné nástroje pro vývoj

Pro bezproblémový a kvalitní vývoj aplikace je bezpodmínečně nutné používat kvalitní vývojové nástroje. Při používání nekvalitních a málo funkčních nástrojů dochází ke zpomalení práce, psaní nepřehledného kódu a tím k následnému vnášení chyb do kódu aplikace. Pro vývoj aplikace jsou používány osvědčené a časem prověřené nástroje (Eclipse, ArgoUML, pgAdmin a další), tudíž pravděpodobnost této chyby je minimální. Důsledek: Pomalý vývoj, chyby v aplikaci, nepřehlednost kódu. Prevence: Využívání kvalitní vývojových nástrojů. Řešitel: Řešitel 3.6.1.2

Nekompatibilita HW a SW

Výsledný softwarový produkt musí být provozovatelný na HW zákazníka. Aplikace vyžaduje podpůrné SW produkty, které jsou prověřené, multiplatformně provozovatelné a výkonné. V požadavcích na provoz aplikace jsou přesně specifikovány požadavky na provoz systému, aby nedošlo k instalaci nesprávných nebo starých verzí podpůrných SW produktů, tudíž je pravděpodobnost tohoto rizika minimální. Důsledek: Nefunkčnost aplikace. Prevence: Dodržování požadavků na provoz aplikace. Řešitel: Řešitel, zákazník 3.6.1.3

Výkonnost HW a SW

Po hardware je aplikací vyžadován definovaný výkon. Tato minimální konfigurace je specifikována v požadavcích pro provoz aplikace. Pokud je aplikace provozována na nedostatečném hardware, její výkonnost je tím omezena a snižuje její použitelnost. Stejné požadavky jsou požadovány též po instalovaném software (např. internetový prohlížeč). Důsledek: Nízká výkonnost aplikace. Prevence: Dodržování požadavků aplikace, používání doporučených utilit. Řešitel: Zákazník

18


3.6.2 3.6.2.1

Rizika procesní Chyby v analýze

Tato chyba má velmi závažný charakter. Pokud je chyba diagnostikována v pozdějších stádiích projektu, její následné odstranění je velmi zdlouhavé a tím také nákladné. Vzhledem k tomu, že se v oblasti vstupenkových systémů již určitou dobu pohybuji a mám zkušenosti, pravděpodobnost chyby je malá. Chyba však může nastat v nesprávném použití Use Case nástrojů a tím dodatečné vnesení chyby do analýzy. Důsledek: Nekorektní chování aplikace. Prevence: Častá komunikace se zákazníkem, studium Use Case nástrojů. Řešitel: Řešitel

3.6.2.2

Odklon od požadavků

Aplikace v tomto případě má např. vlastnosti, které zákazník nepožaduje, příp. fungují jinak, než podle jeho představ nebo požadované vlastnosti neobsahuje. Tyto chyby přímo nevznikají chybou v analýze (i když mají s ní souvislost). Díky vlastní zkušenosti v podobných projektech a komunikaci se zákazníkem je pravděpodobnost chyby minimální. Důsledek: Nekorektní chování aplikace. Prevence: Častá komunikace se zákazníkem, schvalování dílčích komponent. Řešitel: Řešitel, zákazník

3.6.2.3

Špatný odhad velikosti

Špatným odhadem velikosti produktu vzniká několik problémů. V případě podhodnocení je vysoce pravděpodobné zdržení projektu a nedodržení termínů, navíc zvětšení počtu řešitelů zde není přípustné (vzhledem k faktu, že se jedná o diplomovou práci). Důsledek: Nedodržení termínů, zvýšení nákladů. Prevence: Kvalitní odhad, zkušenosti. Řešitel: Řešitel

3.6.3 3.6.3.1

Rizika implementační Nepochopení ovládání

Aplikace by měla být uživatelsky přívětivá a její ovládání intuitivní a pokud možno v celém systému konzistentní. Pokud nejsou tyto požadavky dodrženy, uživatelé se v aplikaci „ztratíÿ a nebudou vědět jak jí ovládat, což povede k výslednému nepřijetí uživateli zákazníka. Vzhledem ke zkušenostem s procesy při prodeji vstupenek a časté komunikaci s uživateli vstupenkových systémů je toto riziko nízké. Důsledek: Nepřijetí uživateli, nízká produktivita. Prevence: Komunikace s uživateli, kvalitní návrh GUI8 . Řešitel: Řešitel, zákazník 8

Grafické uživatelské rozhranní

3.6. ANALÝZA RIZIK 3.6.3.2

19

Znalosti použitých technologií

Pro kvalitní napsání aplikace je důležitá vynikající znalost použitých technologií. V případě neznalosti programátora dochází k nevyužívání potenciálu technologií a pomalému vývoji způsobenému častým vyhledáváním informací a konzultacemi. Vzhledem k mým rozdílným znalostem použitých technologií (např. nízká zkušenost s Java EE technologií) je pravděpodobnost tohoto rizika největší z celého projektu. Důsledek: Pomalý vývoj, neefektivita kódu a aplikace. Prevence: Studium technologií, používání technologií, které známe. Řešitel: Řešitel 3.6.3.3

Nedostatečné testování

Vlivem nedostatečného testování je možné přehlédnutí některých chyb v aplikaci. Tyto chyby se poté projeví až ve fázi nasazení, kdy mohou zákazníkovi způsobit nemalé problémy (provozní i finanční), příp. se projeví až při testování aplikace jako celku a její lokalizace je z globálního hlediska obtížná (oproti testování jednotlivých komponent). Pravděpodobnost této chyby je střední, vzhledem k mé nízké zkušenosti s testovacími mechanismy. Důsledek: Nekorektní chování aplikace. Prevence: Studium fází testování, tvorba modelových postupů. Řešitel: Řešitel

3.6.4 3.6.4.1

Rizika bezpečnostní Chyba SW

Díky chybnému kódu aplikace je možné získat neoprávněný přístup do aplikace. Klasickým příkladem chyby je např. SQL injection, kdy nejsou dostatečně ověřovány vstupy od uživatelů. Důsledek: Nekorektní chování aplikace, zcizení uložených údajů. Prevence: Kvalitní testování, dokumentace kódu. Řešitel: Řešitel 3.6.4.2

Chyba HW

Díky poruše hardwaru dochází k nekorektnímu ukončení aplikace a k možné ztrátě uložených dat. Aplikace by měla být provozována na kvalitním značkovém hardware (servery, stanice) se zajištěným servisem. Včasný servisní zásah je nezbytný pro rychlé obnovení funkčnosti. Pravděpodobnost rizika je závislý na HW používaný zákazníkem. Důsledek: Nefunkčnost aplikace, ztráta dat. Prevence: Redundance HW komponent (např. disků, zdrojů), zálohování. Řešitel: Řešitel, zákazník

20


Kapitola 4

Analýza řešení 4.1

Seznam aktérů

Systém obsahuje detailní správu uživatelských rolí. Vzhledem k této skutečnosti může být seznam aktérů libovolný, tzn. definovatelný za běhu aplikace. Ve výchozím nastavení systém rozlišuje pět základních aktérů (uživatelských rolí): • Externí prodejce Omezený přístup do systému umožňující prodej rezervaci a prodej vstupenek. Vytvořené prodeje a rezervace nemůže (až na několik výjimek) stornovat. • Účetní Omezený přístup do systému za účelem získání statistických a účetních dat o prodeji. • Prodejce vstupenek Může rezervovat, prodávat a stornovat vstupenky a předplatitelské legitimace. Může vystavovat účetní doklady, včetně jejich stornování. Má omezený přístup na vybrané statistiky. • Administrátor Stejné oprávnění jako „Prodejce vstupenekÿ a navíc může spravovat akce (přidávat nové, editovat, rušit), přidávat a měnit slevy a blokace. Administrátor může zakládat a spravovat uživatele, přiřazovat uživatelské role. • Servisní přístup Servisní přístup nemá žádné omezení na volání funkcí systému. Zpřístupňuje např. SQL konzoli pro přímý přístup do databáze aplikace, umožňuje definovat šablony pro formátování tiskových výstupů.

4.2

Analýza případů použití

Případy užití popsané v této kapitole vychází z katalogu požadavků z předchozí kapitoly. Vzhledem k obsáhlosti systému je zde uveden reprezentativní vzorek operací, které lze v systému provést. Případy jsou popsány jazykem UML pomocí Use Case diagramů, Diagramů aktivit a Use Case textů. Pro ilustraci jsou uvedeny navrhy GUI pro některé události. 21

22

KAPITOLA 4. ANALÝZA ŘEŠENÍ

4.2.1

Přihlášení uživatele

Případ Přihlášení uživatele slouží k přihlášení uživatele do systému Aktéři: Systém, Uživatel System

Prihlaseni uzivatele Uzivatel

Obrázek 4.1: Use Case: Prihlášení uživatele

Tabulka 4.1: Use Case: Přihlášení uživatele Krok 1 2 3

Role Systém Uživatel Systém

3a

Systém

Akce Zobrazí přihlašovací stránku Zadá přihlašovací údaje Ověří platnost vložených údajů a přihlásí uživatele do systému Uživatel zadal neplatné přihlašovací údaje: 3a1: Systém zobrazí informaci o neplatném přihlášení a vyzve uživatele k zadání správných údajů (krok 2)

Přihlášení uživatele

neplatné údaje

Zobrazení přihlašovacího formuláře

Vyplnění přihlašovacích údajů

Kontrola údajů

platné údaje

Obrázek 4.2: Activity Diagram: Přihlášení uživatele

4.2.2

Autentizace uživatele

Případ Autentizace uživatele slouží k ověření platnosti přihlášení a oprávnění ke spuštění funkce systému. Autentizace je volána při volání libovolné funkce systému

4.2. ANALÝZA PŘÍPADŮ POUŽITÍ

23

Aktéři: Systém System

Autentizace uzivatele

Obrázek 4.3: Use Case: Autentizace uživatele

Tabulka 4.2: Use Case: Autentizace uživatele Krok 1 2

Role Systém Systém

3 3a

Systém Systém

3b

Systém

4.2.3

Akce Přijme požadavek na funkci systému Ověří platnost přihlášení a oprávnění ke spuštění funkce systému Provede funkci Uživatel není přihlášen nebo mu vypršela doba přihlášení: 3a1: Zobrazí informaci o neplatném přihlášení a vyzve uživatele k zadání správných údajů (krok 2) Uživatel nemá oprávnění pro spuštění funkce systému: 3b1: Zobrazí informaci o nepřiděleném oprávnění

Odhlášení uživatele

Případ Odhlášení uživatele slouží k odhlášení uživatele ze systému a ukončení práce Aktéři: Systém, U6ivatel System


<>

Odhlaseni uzivatele

Obrázek 4.4: Use Case: Odhlášení uživatele

24

KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.3: Use Case: Odhlášení uživatele Krok 1 2 3 4

Role Uživatel Systém Systém Systém

Akce Vybere možnost „Odhlásitÿ Ověří totožnost uživatele (Use Case 4.2) Odhlásí uživatele Zobrazí přihlašovací stránku (Use Case 4.1)

Obrázek 4.5: Návrh GUI: Dialog přihlášení

4.2.4

Změna hesla přihlášeného uživatele

Případ Změna hesla přihlášeného uživatele umožňuje uživateli změnit přihlašovací heslo do systému Aktéři: Systém, Uživatel Tabulka 4.4: Use Case: Změna hesla přihlášeného uživatele Krok 1 2 3 4 5 5a

4.2.5

Role Uživatel Systém Systém Uživatel Systém Systém

Akce Odešle požadavek na změnu hesla Ověří totožnost uživatele (Use Case 4.2) Zobrazí uživateli formulář pro změnu hesla Zadá staré a nové heslo Ověří platnost hesla a změní jej Uživatel zadal neplatné heslo: 5a1: Systém zobrazí informaci o neplatném heslu a vyzve uživatele k zadání správných údajů (krok 3)

Správa uživatelů

Případ Správa uživatelů umožňuje vyhledávat, přidávat, editovat a mazat vybrané uživatele systému Aktéři: Systém, Uživatel


25 System


Smazani uzivatele

<>

<>

Sprava uzivatelu

<>

Seznam uzivatelu

Uzivatel <>

Pridani uzivatele

<> <> Zmena hesla

Editace uzivatele

Obrázek 4.6: Use Case: Správa uživatelů Tabulka 4.5: Use Case: Správa uživatelů Krok 1 2 3 3a

Role Uživatel Systém Systém Systém

3b

Systém

3c

Systém

3d

Systém

3e

Systém

Přidání uživatele

Akce Odešle požadavek na správu uživatelů Ověří totožnost uživatele (Use Case 4.2) Provede příslušný požadavek Přijal požadavek na přidání uživatele: 3a1: Systém zahájí případ Přidání uživatele (Use Case 4.6) Přijal požadavek na editaci uživatele: 3b1: Systém zahájí případ Editace uživatele (Use Case 4.7) Přijal požadavek na změnu hesla uživatele: 3c1: Systém zahájí případ Změna hesla uživatele (Use Case 4.8) Přijal požadavek na smazání uživatele: 3d1: Systém zahájí případ Smazání uživatele (Use Case 4.9) Přijal požadavek na zobrazení seznamu uživatelů: 3e1: Systém zahájí případ Seznam uživatelů (Use Case 4.10)

neplatné údaje

Zobrazení formuláře nového uživatele

Vyplnění údajů

Kontrola údajů

Vytvoření zákazníka

Obrázek 4.7: Activity Diagram: Přidání uživatele

26


4.2.5.1

Přidání uživatele

Případ Přidání uživatele slouží k vytvoření nového uživatele Aktéři: Systém, Uživatel Tabulka 4.6: Use Case: Přidání uživatele Krok 1 2 3 4 4a

4.2.5.2

Role Systém Systém Uživatel Systém Systém

Akce Přijme požadavek na přidání nového uživatele Zobrazí uživateli formulář pro zadání údajů uživatele Zadá údaje o uživateli Ověří platnost údajů a přídá uživatele Uživatel zadal neplatné údaje: 4a1: Systém zobrazí informaci o neplatných údajů a vyzve uživatele k zadání správných údajů (krok 3)

Editace uživatele

Případ Editace uživatele slouží ke změně údajů vybraného uživatele Aktéři: Systém, Uživatel Tabulka 4.7: Use Case: Editace uživatele Krok 1 2


3 4 4a

Uživatel Systém Systém

4.2.5.3

Akce Přijme požadavek na editaci uživatele Načte údaje o vybraném uživateli a zobrazí uživateli formulář pro změnu údajů vybraného uživatele s předvyplněnými aktuálními údaji Zadá údaje o uživateli Ověří platnost údajů a změní údaje uživatele Uživatel zadal neplatné údaje: 4a1: Systém zobrazí informaci o neplatných údajů a vyzve uživatele k zadání správných údajů (krok 3 - bez načítání údajů)

Změna hesla uživatele

Případ Změna hesla uživatele slouží ke změně hesla vybraného uživatele Aktéři: Systém, Uživatel


27

Tabulka 4.8: Use Case: Změna hesla uživatele Krok 1 2


3 4 4a


Akce Přijme požadavek na změnu hesla uživatele Zobrazí uživateli formulář pro změnu hesla vybraného uživatele Zadá nové heslo vybraného uživatele Ověří platnost hesla a změní jej u vybraného uživatele Uživatel zadal neplatné heslo: 4a1: Systém zobrazí informaci o neplatném heslu a vyzve uživatele k zadání správného hesla (krok 3)

Změna hesla uživatele

neplatné údaje

Zobrazení formuláře změny hesla

Vyplnění údajů

Kontrola údajů

Změna hesla

Obrázek 4.8: Activity Diagram: Změna hesla uživatele

Obrázek 4.9: Návrh GUI: Změna hesla uživatele

4.2.5.4

Smazání uživatele

Případ Smazání uživatele slouží k odstranění vybraného uživatele Aktéři: Systém Tabulka 4.9: Use Case: Smazání uživatele Krok 1 2 2a

Role Systém Systém Systém

Akce Přijme požadavek na smazání vybraného uživatele Smaže vybraného uživatele Uživatel nelze smazat (datová integrita): 2a1: Systém zobrazí informaci neprovedeném smazání

28


4.2.5.5

Seznam uživatelů

Případ Seznam uživatelů slouží k vypsání seznamu uživatelů Aktéři: Systém Tabulka 4.10: Use Case: Seznam uživatelů Krok 1 2 2a


2b

Systém

Akce Přijme požadavek na zobrazení seznamu uživatelů Zobrazí seznam uživatelů Uživatel má oprávnění uživatele mazat: 2a1: Systém zobrazí seznam uživatelů s možností mazání uživatele (Use Case 4.9) Uživatel má oprávnění uživatele editovat: 2b1: Systém zobrazí seznam uživatelů s možností editace uživatele (Use Case 4.7)


Zobrazení potvrzení smazání uživatele

NE ANO


Obrázek 4.10: Activity Diagram: Smazání uživatele

Obrázek 4.11: Návrh GUI: Správa uživatelů


4.2.6

29

Vytvoření nového zákazníka

Případ Vytvoření nového zákazníka slouží k založení nového zákazníka a vyplnění jeho údajů Aktéři: Systém, Uživatel System


<>

Vytvoreni noveho zakaznika Uzivatel

Obrázek 4.12: Use Case: Vytvoření nového zákazníka

Tabulka 4.11: Use Case: Vytvoření nového zákazníka Krok 1 2 3 4 5

Role Uživatel Systém Systém Uživatel Systém

5a

Systém

Akce Odešle požadavek na vytvoření nového zákazníka Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář pro zadání údajů Zadá údaje zákazníka Ověří platnost vložených údajů a přidá zákazníka do systému Uživatel zadal neplatné údaje: 5a1: Systém zobrazí informaci o neplatných údajích a vyzve uživatele k zadání správných údajů (krok 2)

Vytvoření nového zákazníka

Zobrazení formuláře nového zákazníka

neplatné údaje

Vyplnění údajů

Kontrola údajů

Vytvoření zákazníka

Obrázek 4.13: Activity Diagram: Vytvoření zákazníka

4.2.7

Vyhledání zákazníka

Případ Vyhledání zákazníka slouží k založení nového zákazníka a vyplnění jeho údajů Aktéři: Systém, Uživatel

30


System


Smazani zakaznika

<>

Vyhledani zakaznika

<>

Slouceni zakaznika

Uzivatel <> <> Je-li povoleno Editace zakaznika

Obrázek 4.14: Use Case: Vyhledání zákazníka Tabulka 4.12: Use Case: Vyhledání zákazníka Krok 1 2 3 4 5 6 6a

Role Uživatel Systém Systém Uživatel Systém Systém Systém

6b

Systém

6c

Systém

4.2.7.1

Akce Odešle požadavek na vyhledání zákazníka Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář pro zadání vyhledávacích kritérií Zadá vyhledávací kritéria Vyhledá zákazníky podle zadaných kritérií Zobrazí vyhledaný seznam zákazníků Uživatel má oprávnění zákazníka smazat: 6a1: Systém zobrazí seznam zákazníků s možností mazání zákazníka (Use Case 4.13) Uživatel má oprávnění zákazníka editovat: 6b1: Systém zobrazí seznam zákazníků s možností editace zákazníka (Use Case 4.14) Uživatel má oprávnění zákazníka sloučit a slučování je povoleno: 6c1: Systém zobrazí seznam zákazníků s možností sloučení zákazníka (Use Case 4.15)

Smazání zákazníka

Případ Smazání zákazníka slouží ke smazání zákazníka Aktéři: Systém Tabulka 4.13: Use Case: Smazání zákazníka Krok 1 2 3 3a

Role Systém Systém Systém Systém

Akce Přijme požadavek na smazání zákazníka Ověří totožnost uživatele (Use Case 4.2) Smaže vybraného uživatele Zákazník nelze smazat (datová integrita): 3a1: Systém zobrazí informaci neprovedeném smazání

4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 4.2.7.2

Editace zákazníka

Případ Editace zákazníka slouží ke změně uložených údajů zákazníka Aktéři: Systém, Uživatel Tabulka 4.14: Use Case: Editace zákazníka Krok 1 2 3


4 5 5a


Akce Přijme požadavek na editaci zákazníka Ověří totožnost uživatele (Use Case 4.2) Načte údaje o vybraném zákazníkovi a zobrazí uživateli formulář pro změnu údajů zákazníka s předvyplněnými aktuálními údaji Zadá údaje o zákazníkovi Ověří platnost údajů a změní údaje zákazníka Uživatel zadal neplatné údaje: 5a1: Systém zobrazí informaci o neplatných údajů a vyzve uživatele k zadání správných údajů (krok 3 - bez načítání údajů)

Obrázek 4.15: Návrh GUI: Editace zákazníka

31

32


Editace zákazníka

neplatné údaje

Zobrazení formuláře editace zákazníka

Vyplnění údajů

Kontrola údajů

Změna údajů zákazníka

Obrázek 4.16: Activity Diagram: Editace zákazníka 4.2.7.3

Sloučení zákazníka

Případ Sloučení zákazníka slouží ke sloučení dvou zákazníků v jednoho. Tento případ je vhodný především pro odstraňování duplicitních údajů, kdy jsou 2 zákazníci sloučeni pod jedním identifikačním číslem. Aktéři: Systém, Uživatel Tabulka 4.15: Use Case: Sloučení zákazníka Krok 1 2 3 4 5 4a

Role Systém Systém Systém Uživatel Systém Zákazník

Akce Přijme požadavek na sloučení zákazníka Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář pro zadání slučovaných zákazníků Vyplní formulář Ověří platnost údajů a provede sloučení Zákazník pro výběr zákazníka použije případ Vyhledání zákazníka se zakázaným slučováním (Use Case 4.12)

Obrázek 4.17: Návrh GUI: Vyhledání zákazníka


33


Zobrazení formuláře sloučení zákazníka

Vyplnění údajů

Vyhledání zákazníka


Obrázek 4.18: Activity Diagram: Sloučení zákazníka

4.2.8

Seznam akcí

Případ Seznam akcí slouží k zobrazení konaných akcí. Ze seznamu je možné vybírat akce, ve kterých lze následně vybírat a vkládat sedadla do nákupního košíku. V seznamu akcí je u každé akce zobrazován aktuální stav volných a rezervovaných míst. V případě potřeby detailního náhledu je možné zobrazit plánek hlediště s aktuálním stavem. Aktéři: Systém, Uživatel System


<> Vyhledani akce <<extend>> Seznam akci Uzivatel <>

Detail akce

<>

Vyber sedadel

Obrázek 4.19: Use Case: Seznam akcí

Tabulka 4.16: Use Case: Seznam akcí Krok 1 2 3 4

Role Uživatel Systém Systém Uživatel

Akce Odešle požadavek na Seznam akcí Ověří totožnost uživatele (Use Case 4.2) Zobrazí seznam akcí Prohlíží seznam akcí

34

KAPITOLA 4. ANALÝZA ŘEŠENÍ Krok 1a

Role Uživatel

4a

Uživatel

4b

Uživatel

Akce Uživatel odešle požadavek na vyhledání akce: 1a1: Systém provede případ Vyhledání akce (Use Case 4.19) Uživatel odešle požadavek na výběr sedadel v akci: 4a1: Systém zobrazí formulář výběr sedadel (Use Case 4.17) Uživatel odešle požadavek na detail akce: 4b1: Systém zobrazí formulář detail akce (Use Case 4.18)

Obrázek 4.20: Návrh GUI: Seznam akcí

4.2.8.1

Výběr sedadel

Případ Výběr sedadel slouží k výběru sedadel jednotlivé akce a jejich následné vložení do nákupního košíku. Pro výběr sedadel je zobrazen dialog s hledištěm. Sedadla jsou různě obarvena podle jejich stavu (volná, blokovaná, rezervovaná, prodaná, obsazena předplatitelskou legitimací). V průběhu výběru mohou uživatele volit z nabízených slev a aplikovat je na vybíraná sedadla. Aktéři: Systém, Uživatel Tabulka 4.17: Use Case: Výběr sedadel Krok 1 2 3 4 5 5a

Role Systém Systém Systém Uživatel Systém Systém

Akce Přijme požadavek na výběr sedadel Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář s hledištěm k výběru sedadel Vybere sedadla k odeslání, včetně výběru slev Zkontroluje vkládaná sedadla a vloží je do nákupního košíku Sedadlo je již obsazeno: 5a1: Systém zobrazí informaci o obsazenosti sedadel a vyzve uživatele k opravě zadání (krok 3)


Výběr sedadel

35

Sedadla obsazena

Zobrazení dialogu výběru sedadel

Výběr sedadel

Kontrola obsazenosti

Vložení sedadel do košíku

Obrázek 4.21: Activity Diagram: Výběr sedadel

Obrázek 4.22: Návrh GUI: Výběr sedadel

4.2.8.2

Detail akce

Případ Detail akce slouží k zobrazení hlediště s aktuálním stavem prodejnosti. Aktéři: Systém, Uživatel Tabulka 4.18: Use Case: Detail akce Krok 1 2 3 4 4a

Role Systém Systém Systém Uživatel Uživatel

Akce Přijme požadavek na zobrazení detailu akce Ověří totožnost uživatele (Use Case 4.2) Zobrazí detail akce Prohlíží detail akce Uživatel vybere detail sedadla: 4a1: Systém zobrazí informaci o vybraném sedadle

36


4.2.8.3

Vyhledání akce

Případ Vyhledání akce slouží k nalezení akce dle vyhledávacích kritérií. Aktéři: Systém, Uživatel Tabulka 4.19: Use Case: Vyhledání akce Krok 1 2 3 4 5 6 7

4.2.9

Role Systém Systém Systém Uživatel Systém Systém Uživatel

Akce Přijme požadavek na vyhledání akce Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář pro zadání vyhledávacích kritérií Zadá vyhledávací kritéria Vyhledá akce podle zadaných kritérií Zobrazí vyhledaný seznam akcí Pokračuje případem Seznam akcí (Use Case 4.16 - krok 4)

Vytvoření nové legitimace

Případ Vytvoření nové legitimace slouží k založení nové předplatitelské legitimace a její následné vložení do nákupního košíku. Aktéři: Systém, Uživatel System

Vytvoreni legitimace Uzivatel <>

Vytvoreni fixni predplatne

<>


<>

Vytvoreni volne predplatne

Obrázek 4.23: Use Case: Vytvoření nové legitimace

Tabulka 4.20: Use Case: Vytvoření nové legitimace Krok 1 2 3 4 5

Role Uživatel Systém Systém Uživatel Systém

Akce Odešle požadavek na vytvoření nové legitimace Ověří totožnost uživatele (Use Case 4.2) Zobrazí uživateli výběr typu legitimace Vybere typ legitimace Zpracuje požadavek uživatele

4.2. ANALÝZA PŘÍPADŮ POUŽITÍ Krok 5a

Role Uživatel

5b

Uživatel

37

Akce Uživatel vybere fixní typ předplatného: 5a1: Systém zpracuje vytvoření fixního předplatného (Use Case 4.21) Uživatel vybere volný typ předplatného: 5b1: Systém zpracuje vytvoření volného předplatného (Use Case 4.22)

Vytvoření legitimace Zobrazení formuláře s výběrem typu

Výběr typu předplatného

Volné předplatné

Vygenerování legitimace Fixní předplatné

Sedadlo volné Kontrola obsazenosti

Výběr sedadla

Zobrazení výběru sedadla

Zobrazení formuláře s výběrem cenové zóny

Výběr zóny

Sedadlo obsazeno

Obrázek 4.24: Activity Diagram: Vytvoření nové legitimace

4.2.9.1

Vytvoření fixního předplatného

Případ Vytvoření fixního předplatného zajišťuje výběr sedadla pro umístění legitimace. Aktéři: Systém, Uživatel Tabulka 4.21: Use Case: Vytvoření fixního předplatného Krok 1 2 3 4 4a

4.2.9.2


Akce Přijme požadavek na vytvoření legitimace Zobrazí formulář pro výběr sedadla Vybere sedadlo Vytvoří legitimaci fixního předplatného a vloží ji do košíku Sedadlo je již obsazeno: 4a1: Systém zobrazí informaci o obsazenosti sedadla a vyzve uživatele k opravě zadání (krok 2)

Vytvoření volného předplatného

Případ Vytvoření volného předplatného zajišťuje výběr cenové zóny pro volné předplatné. Aktéři: Systém, Uživatel

38

KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.22: Use Case: Vytvoření volného předplatného Krok 1 2 3 4

4.2.10

Role Systém Systém Uživatel Systém

Akce Přijme požadavek na vytvoření legitimace Zobrazí formulář pro výběr cenové zóny Vybere cenovou zónu Vytvoří legitimaci volného předplatného a vloží ji do košíku

Nákupní košík

Případ Nákupní košík zajišťuje v systému logiku nákupního košíku. Každý uživatel v systému má svůj vlastní košík. Vybraná sedadla a legitimace jsou nejprve vkládána do nákupního košíku. Z košíku je možné jednotlivé položky mazat a editovat, včetně smazání celého košíku. Vstupenky vložené v košíku může uživatel zarezervovat, vstupenky a legitimace také prodat. Další možností je z košíku vytvořit zakázku, se kterou je možné poté dál pracovat. Rozdíl mezi zakázkou a košíkem je pouze ten, že zakázka má již v systému přiděleno číslo. Zakázka nemusí být prodaná, může být zatím pouze uložena (zakázka je otevřená) - z takovou zakázkou se dále pracuje jako s košíkem. Aktéři: Systém, Uživatel System

Vyber zakaznika Autentizace uzivatele <> <>

Vytvoreni zakazky <>

Nakupni kosik <> Uzivatel

<> Prohlizeni kosiku

<>

Smazani kosiku

Prodej kosiku <>

Rezervace kosiku

Obrázek 4.25: Use Case: Nákupní košík

Tabulka 4.23: Use Case: Nákupní košík Krok 1 2 3

Role Uživatel Systém Systém

Akce Odešle požadavek na práci z košíkem Ověří totožnost uživatele (Use Case 4.2) Provede příslušný požadavek

4.2. ANALÝZA PŘÍPADŮ POUŽITÍ Krok 3a

Role Systém

3b

Systém

3c

Systém

3d

Systém

3e

Systém

3f

Systém

4.2.10.1

Akce Přijal požadavek na prohlížení košíku: 3a1: Systém zahájí případ Prohlížení košíku (Use Case 4.24) Přijal požadavek na smazání košíku: 3b1: Systém zahájí případ Smazání košíku (Use Case 4.25) Přijal požadavek na rezervaci košíku: 3c1: Systém zahájí případ Rezervaci košíku (Use Case 4.26) Přijal požadavek na prodej košíku: 3d1: Systém zahájí případ Prodej košíku (Use Case 4.27) Přijal požadavek na vytvoření zakázky: 3e1: Systém zahájí případ Vytvoření zakázky (Use Case 4.28) Přijal požadavek na výběr zákazníka: 3f1: Systém zahájí případ Výběr zákazníka (Use Case 4.29)

Prohlížení košíku

Případ Prohlížení košíku slouží k zobrazení obsahu košíku Aktéři: Systém Tabulka 4.24: Use Case: Prohlížení košíku Krok 1 2


Akce Přijme požadavek na prohlížení košíku Zobrazí uživateli obsah košíku

Obrázek 4.26: Návrh GUI: Vzhled košíku

4.2.10.2

Smazání košíku

Případ Smazání košíku slouží k odstranění obsahu košíku Aktéři: Systém

39

40

KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.25: Use Case: Smazání košíku Krok 1 2

4.2.10.3


Akce Přijme požadavek na smazání košíku Smaže košík

Rezervace košíku

Případ Rezervace košíku slouží k rezervaci vstupenek uložených v košíku. Rezervace jsou ukládány po jednotlivých akcích. Aktéři: Systém, Uživatel Tabulka 4.26: Use Case: Rezervace košíku Krok 1 2 3 4 5 4a

Role Systém Systém Uživatel Systém Systém Systém

Akce Přijme požadavek na rezervaci Zobrazí uživateli formulář pro zadání rezervace Zadá údaje o rezervaci Ověří platnost údajů a vytvoří rezervace Zarezervované vstupenky odstraní z košíku Uživatel zadal neplatné údaje: 4a1: Systém zobrazí informaci o neplatných údajích a vyzve jej k zadání správných údajů (krok 2)

Obrázek 4.27: Návrh GUI: Rezervace košíku

4.2.10.4

Prodej košíku

Případ Prodej košíku slouží k prodeji obsahu košíku, a následným akcím (zaúčtovaní, vytvoření dokladu, tisk vstupenek). Aktéři: Systém, Uživatel


41

Tabulka 4.27: Use Case: Prodej košíku Krok 1 2 3 4 5


Akce Přijme požadavek na prodej Zobrazí uživateli formulář pro zadání údajů prodeje Zadá údaje o prodeji (volba platby) Prodá položky košíku a košík vyčistí Vytvoří zaúčtování, doklady a zajistí tisk vstupenek

Prodej košíku

Zobrazení formuláře prodeje košíku

Vyplnění údajů

Zaúčtování prodaných položek

Vytvoření dokladu a tisk vstupenek

Obrázek 4.28: Activity Diagram: Prodej košíku

Obrázek 4.29: Návrh GUI: Prodej košíku

4.2.10.5

Vytvoření zakázky

Případ Vytvoření zakázky slouží vytvoření nové zakázky, obsah košíku je vložen do nově vzniklé zakázky. Aktéři: Systém

42

KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.28: Use Case: Vytvoření zakázky Krok 1 2 3 4 4a


Akce Přijme požadavek na vytvoření zakázky Zobrazí uživateli formulář pro zadání údajů zakázky Zadá údaje o zakázce Ověří platnost údajů a vytvoří zakázku Uživatel zadal neplatné údaje: 4a1: Systém zobrazí informaci o neplatných údajů a vyzve uživatele k zadání správných údajů (krok 3)


neplatné údaje

Zobrazení formuláře vytvoření zakázky

Vyplnění údajů

Kontrola údajů


Obrázek 4.30: Activity Diagram: Vytvoření zakázky

Obrázek 4.31: Návrh GUI: Prodej košíku

4.2.10.6

Výběr zákazníka

Případ Výběr zákazníka slouží nalezení a výběru zákazníka, kterému je poté košík nebo zakázka prodána. Aktéři: Systém, Uživatel


43

Tabulka 4.29: Use Case: Výběr zákazníka Krok 1 2


3 4

Uživatel Systém

4.2.11

Akce Přijme požadavek na výběr zákazníka Zobrazí uživateli formulář pro vyhledání zákazníka (Use Case 4.12) Vybere zákazníka Přijme vybraného zákazníka

Seznam zakázek

Případ Seznam zakázek zajišťuje akce uživatele se zakázkami. Zakázky můžeme vyhledávat, editovat, příp. mazat/stornovat podle toho, zda již byly vyfakturovány nebo ne. Nevyfakturované zakázky je možné dodatečně vyfakturovat (prodat). Aktéři: Systém, Uživatel System


<>

1

Vyhledani zakazky

<<extend>> Editace zakazky

<>

1

Zakazka otevrena

Seznam zakazek

<> <>

Uzivatel

Vystaveni dokladu

<> Vyber zakaznika Storno zakazky

<>

Vyhledani zakaznika

Obrázek 4.32: Use Case: Seznam zakázek

Tabulka 4.30: Use Case: Správa zakázek Krok 1 2 3 4 1a

Role Uživatel Systém Systém Uživatel Uživatel

4a

Uživatel

Akce Odešle požadavek na Seznam zakázek Ověří totožnost uživatele (Use Case 4.2) Zobrazí seznam zakázek Prohlíží seznam zakázek Uživatel odešle požadavek na vyhledání zakázky: 1a1: Systém provede případ Vyhledání zakázky (Use Case 4.31) Uživatel odešle požadavek na storno zakázky: 4a1: Systém provede případ Storno zakázky (Use Case 4.32)

44

KAPITOLA 4. ANALÝZA ŘEŠENÍ Krok 4b

4.2.11.1

Role Uživatel

Akce Uživatel odešle požadavek na editaci zakázky: 4b1: Systém zobrazí formulář Editace zakázky (Use Case 4.33)

Vyhledání zakázky

Případ Vyhledání zakázky slouží nalezení zakázky dle vyhledávacích kritérií. Aktéři: Systém, Uživatel Tabulka 4.31: Use Case: Vyhledání zakázky Krok 1 2 3 4 5 6 7

Role Systém Systém Systém Uživatel Systém Systém Uživatel

Akce Přijme požadavek na vyhledání zakázky Ověří totožnost uživatele (Use Case 4.2) Zobrazí formulář pro zadání vyhledávacích kritérií Zadá vyhledávací kritéria Vyhledá akce podle zadaných kritérií Zobrazí vyhledaný seznam zakázek Pokračuje případem Seznam zakázek (Use Case 4.30 - krok 4)

Vyhledání / Seznam zakázky

vyhledání

seznam

Zobrazení formuláře vyhledání zakázky

Načtení zakázek

Vyplnění údajů

Vyhledání zakázek

Zobrazení zakázek

Obrázek 4.33: Activity Diagram: Vyhledání / Seznam zakázky

4.2.11.2

Storno zakázky

Případ Storno zakázky slouží ke stornování zakázky. Systém automaticky vytvoří potřebné zaúčtování a storno doklad. Aktéři: Systém, Uživatel


45

Tabulka 4.32: Use Case: Storno zakázky Krok 1 2 3 4 5

4.2.11.3


Akce Přijme požadavek na storno zakázky Zobrazí uživateli formulář pro stornování zakázky Vyplní formulář (typ platby) Vystornuje zakázku Vytvoří zaúčtování a storno doklad

Editace zakázky

Případ Editace zakázky slouží ke zobrazení detailu zakázky, změně zákazníka a případné vyfakturování dosud otevřené zakázky. Otevřená zakázka je zakázka, kterou ještě nebyla vyfakturována. Aktéři: Systém, Uživatel Tabulka 4.33: Use Case: Editace zakázky Krok 1 2 3 3a

Role Systém Systém Uživatel Uživatel

3b

Uživatel

Akce Přijme požadavek na editaci zakázky Zobrazí uživateli formulář pro editaci zakázky Prohlíží podrobnosti zakázky ve formuláři editace zakázky Uživatel odešle požadavek na výběr zákazníka: 3a1: Systém provede případ Výběr zákazníka (Use Case 4.29) Uživatel odešle požadavek na vystavení dokladu: 3b1: Systém zobrazí formulář Vystavení dokladu (Use Case 4.34)

Editace zakázky změna zákazníka Načtení formuláře editace zakázky

Výběr zákazníka

uložení zakázky

ANO

Uložení zakázky NE

akce

vystavení dokladu

Načtení dialogu vystavení dokladu

Zadání parametrů

Vystavení dokladu

Obrázek 4.34: Activity Diagram: Editace zakázky

46


Obrázek 4.35: Návrh GUI: Editace zakázky 4.2.11.4

Vystavení dokladu

Případ vystavení dokladu složí k vyfakturování otevřené zakázky. Aktéři: Systém, Uživatel Tabulka 4.34: Use Case: Vystavení dokladu Krok 1 2 3 4 1a

Role Systém Systém Uživatel Systém Uživatel

Akce Přijme požadavek na vystavení dokladu Zobrazí uživateli formulář pro vystavení dokladu Zadá parametry vystavovaného dokladu Vytvoří zaúčtování a doklad Doklad k zakázce je již vystaven: 1a1: Systém zobrazí informaci o již vystaveném dokladu

Vystavení dokladu

Zobrazení formuláře vystavení dokladu

Vyplnění parametrů dokladu

Vytvoření zaúčtování

Vystavení dokladu

Obrázek 4.36: Activity Diagram: Vystavení dokladu

4.3. KONCEPTUÁLNÍ DATOVÝ MODEL

4.3

47

Konceptuální datový model

Konceptuální datový model vychází z kapitoly 3.3. Jedná se o model doménových objektů sféry působení aplikace, který bude základem pro návrh fyzického datového úložiště. V systému jsou evidovány akce, ve kterých jsou konána představení. Každé představení obsahuje hru (název konaného představeni - titul). Akce jsou konány v definovaných hledištích. Na představení je možné prodat sedadla (prodeje) nebo legitimace (abonma + návštěvy). Každá legitimace obsahuje předplacený počet návštěv, což je speciální druh vstupenky. Legitimace jsou definovány typem a zónou. Vstupenky a legitimace je možné sdružovat do zakázek, ke kterým jsou posléze vystaveny doklady. Úhrady dokladů jsou uloženy v seznamu plateb. Každá zakázka může být prodána zákazníkovi (uložený v seznamu kontaktů) nebo anonymně (anonymní prodej na pokladně). hry

prodeje

zakazky

kontakty 0..1

1 0..*

hlediste

0..*

1

0..*

0..*

1

1

1

0..*

predstaveni

navstevy

abonma 1

1..* rezervace

1

0..*

akce

1 doklady

1..* 1

1

0..*

0..*

1 0..* 0..* typy

1

0..1

0..*

1 zony

platby

Obrázek 4.37: Konceptuální datový model • hlediště Třída obsahující definici jednotlivých hledišť. • akce Třída obsahuje informace o konané akci. Obsahuje odkaz na aktuálně konané představení • představení Třída představeni obsahuje čas a hru, která je v akci konána. Akce může obsahovat více představení (pouze jediné aktuální), představení se může v rámci akce změnit, původní představeni je však pro zachování historie zachováno. • hry Třída obsahující názvy konaného představení (tituly). • rezervace Třída obsahuje rezervace vstupenek. Rezervace je skupina vstupenek rezervovaných na jméno. Rezervacím je možné nastavit datum vypršení, kdy mají být automaticky zrušeny.

48

KAPITOLA 4. ANALÝZA ŘEŠENÍ • prodeje Třída prodeje obsahuje informace o jednotlivých sedadlech prodaných na dané představení. Prodejem se rozumí jedno prodané sedadlo. K prodanému sedadlu je možné vytisknout vstupenku, příp. duplikát vstupenky. • abonma Třída definující předplatitelskou legitimaci. Legitimace je určitého typu (třída typy) a má přiřazenou cenovou zónu (třída zóna). Legitimace obsahuje volitelný počet návštěv (třída návštěvy), možností shlédnout vybranou akci v rámci předplatitelské legitimace. • návštěvy Třída obsahuje informace o jednotlivých návštěvách v rámci legitimace. Návštěva obsahuje jedno prodané sedadlo v daném představení a nahrazuje prodej (vstupenku). • typy Třída obsahující typy legitimací. Typ legitimace určuje její předplatitelskou skupinu, počet návštěv a cenové zóny. • zóny Třída obsahuje cenové zóny legitimací. Každá cenová zóna definuje parametry výpočtu ceny legitimace pro jednotlivé zóny a typy legitimací. • kontakty Třída obsahuje všechny zákazníky systému. Tyto zákazníci jsou přiřazováni k jednotlivým zakázkám. • doklady Třída obsahuje vystavené účetní doklady k zakázkám. • platby Třída obsahuje informace o provedených platbách, úhradách dokladů. • zakázky Třída obsahuje zakázky, seskupení vstupenek a legitimací v rámci jedné objednávky zákazníkem. K zakázce je možné vystavit potřebné doklady.

Kapitola 5

Návrh a Implementace 5.1

Fyzický datový model

Níže uvedený datový model ve formě ER-Diagramu obsahuje nejdůležitější databázové tabulky systému ve schématu PUBLIC. Systém obsahuje další schémata CISELNIKY, GEMINI (obsahuje konfigurační tabulky), CRON (místo pro ukládání uložených procedur modulu „cronÿ, GPS (obsahuje tabulky pro tiskový subsystém), XML (místo pro ukládání uložených procedur generujících XML statistiky). Fyzický datový model vychází z konceptuální datového modelu z předchozí kapitoly a definuje přímo databázové tabulky.

49

50

KAPITOLA 5. NÁVRH A IMPLEMENTACE

Obrázek 5.1: ER Diagram

5.1. FYZICKÝ DATOVÝ MODEL

5.1.1

51

Databázové tabulky

Tabulka abonma je určena k ukládání předplatitelských legitimací. Legitimace je určitého typu (id typu) a má přiřazeno cenovou zónu (id zony). Tabulka 5.1: Databázová tabulka: abonma Key PK FK FK FK

FK

Název id abonma id typu id zony id zakazky aktivni id sedadla cislo cena cena dph dph typ id uzivatele dt

Typ SERIAL INTEGER INTEGER INTEGER BOOLEAN INTEGER VARCHAR(16) DECIMAL(8,2) DECIMAL(8,2) SMALLINT INTEGER TIMESTAMP

Null NO NO NO NO YES YES YES NO NO NO NO NO

Default

true

0 CURRENT TIMESTAMP

Tabulka abonmatypy obsahuje jednotlivé typy (skupiny) předplatitelských legitimací. Atribut typ určuje, zda se jedná o předplatné vázané nebo volné. Platnost typu je možné omezit paramtry dt od a dt do. Ke každému záznamu v tabulce jsou vázány záznamy v tabulce abonmatypyd, jejich počet je roven počtu návštěv v předplatném. Každý typ (skupina) může obsahovat několiv zón (tabulka abonmazony), které rozdělují jeden typ podle cen (omezení, kam si zákazník může sednout) Tabulka 5.2: Databázová tabulka: abonmatypy Key PK

FK

Název id typu typ nazev dt od dt do id hlediste

Typ SERIAL ab typy VARCHAR(32) DATE DATE INTEGER

Null NO NO NO NO NO YES

Default

Tabulka abonmnatypyd obsahuje parametry návštěv jednoho typu (skupina) předplatného. Je možné přiřadit konkrétní akci, kterou má zákazník navštívit (id akce) nebo jenom typ akce (typ akce).

52

KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.3: Databázová tabulka: abonmatypyd Key PK FK

FK FK

Název id typud id typu nazev voucher inverze id akce typ akce

Typ SERIAL INTEGER VARCHAR(32) BOOLEAN BOOLEAN INTEGER INTEGER

Null NO NO NO NO NO YES YES

Default

false false

Tabulka abonmazony obsahuje seznam cenových zón k danému typu předplatného. Tabulka 5.4: Databázová tabulka: abonmazony Key PK FK

Název id zony id typu nazev

Typ INTEGER INTEGER VARCHAR(32)

Null NO NO NO

Default

Tabulka abonmazonyd obsahuje parametry cenové zóny pro každou návštěvu. Pro každou návštěvu je možné nastavit parametry samostatně. Tabulka 5.5: Databázová tabulka: abonmazonyd Key FK FK

Název id zony id typud cenax k q

Typ INTEGER INTEGER DECMAL(8,2) DECMAL(5,2) DECMAL(8,2)

Null NO NO YES NO NO

Default

1 0

Tabulka abonmad obsahuje záznam pro jednotlivé návštěvy v předplatitelské legitimaci. Tento záznam nahrazuje prodanou vstupenku, jeho cena je poměrná část předplatného - cena je vypočtena podle parametrů cenové zóny. Tabulka 5.6: Databázová tabulka: abonmad Key PK

Název id abonmad

Typ SERIAL

Null NO

Default

5.1. FYZICKÝ DATOVÝ MODEL Key FK FK

FK

FK

Název id abonma id zakazky aktivni cislo id predstaveni id sedadla cena cena dph zaloha zaloha dph dph typ id uzivatele dt

53

Typ INTEGER INTEGER BOOLEAN VARCHAR(16) INTEGER INTEGER DECIMAL(8,2) DECIMAL(8,2) DECIMAL(8,2) DECIMAL(8,2) SMALLINT INTEGER TIMESTAMP

Null NO NO YES YES YES YES NO NO NO NO NO NO NO

Default

true

0 0

0 CURRENT TIMESTAMP

Tabulka akce poskytuje seznam nasazených akcí v systému. Akce obsahuje atribut id predstaveni, který odkazuje na aktualní představení konané v akci (více u tabulky predstaveni ). Tabulka 5.7: Databázová tabulka: akce Key PK FK FK

Název id akce id hlediste id predstaveni aktivni uzamceno neadresni mista export stav poznamka sync ts

Typ SERIAL INTEGER INTEGER BOOLEAN BOOLEAN INTEGER SMALLINT VARCHAR(16) TIMESTAMP

Null NO NO NO NO NO NO NO YES NO

Default

true false 0 0 CURRENT TIMESTAMP

Vazební tabulka akcecenovekategorie ukládá vazby mezi jednotlivými akcemi a cenovými kategoriemi. Pro každou akci je možné nastavit parametry cenových kategorií samostatně. Cenové kategorie jsou přiřazovány zákazníkům. Tabulka 5.8: Databázová tabulka: akcecenovekategorie Key FK FK

Název id akce id kategorie k q slevy

Typ INTEGER INTEGER DECIMAL(5,2) DECIMAL(8,2) BOOLEAN

Null NO NO NO NO NO

Default

1 0 false

54


Tabulka akcedata obsahuje volitelné údaje o akci, je použito schéma klíč-hodnota. Tabulka 5.9: Databázová tabulka: akcedata Key FK FK

Název id akce klic hodnota

Typ INTEGER VARCHAR(16) VARCHAR(64)

Null NO NO NO

Default

Vazební tabulka akceslevy obsahuje povolené slevy pro vybranou akci. Tabulka 5.10: Databázová tabulka: akceslevy Key FK FK

Název id akce id slevy

Typ INTEGER INTEGER

Null NO NO

Default

Vazební tabulka akcetypy obsahuje seznam, jakých typů je daná akce. Tabulka 5.11: Databázová tabulka: akcetypy Key FK FK

Název id akce id typu

Typ INTEGER INTEGER

Null NO NO

Default

Tabulka akced obsahuje informace o jednotlivých sedadlech v akci. Primárním klíčem je dvojice id akce a id sedadla. Sedadlu je přiřazena blokace a barva, atribut stav určuje aktuální stav sedadla (volné, prodané, atd.). Atribut sync ts slouží k inkrementální synchronizaci s externími systémy - obsahuje TIMESTAMP poslední změny. Tabulka 5.12: Databázová tabulka: akced Key PK PK

Název id akce id sedadla stav cena barva

Typ SERIAL INTEGER akced stavy DECIMAL(8,2) VARCHAR(6)

Null NO NO NO NO NO

Default

volno -1 ffffff

5.1. FYZICKÝ DATOVÝ MODEL Key FK

Název id blokace sync ts

55

Typ INTEGER TIMESTAMP

Null NO NO

Default 0 CURRENT TIMESTAMP

Tabulka blokace obsahuje seznam blokací. Tabulka 5.13: Databázová tabulka: blokace Key PK

Název id blokace nazev barva aktivni

Typ INTEGER VARCHAR(32) VARCHAR(6) BOOLEAN

Null NO NO YES YES

Default

true

Vazební tabulka blokaceuzivatele přiřazuje jednotlivé uživatele k blokacím, tím je určeno, kteří uživatelé mají k dané blokaci přístup. Tabulka 5.14: Databázová tabulka: blokaceuzivatele Key FK FK

Název id blokace id uzivatele

Typ INTEGER INTEGER

Null NO NO

Default

Tabulka doklady zajišťuje úložiště pro všechny vygenerované doklady v systému. Typ dokladu určuje parametr typ dokladu (např. faktura, dobropis, a další), forma úhrady je uložena v atributu typ platby. Pokud je potřeba doklad smazat, nastavíme atribut aktivní na false. Tabulka 5.15: Databázová tabulka: doklady Key PK FK FK

Název id dokladu id zakazky id platby typ typ platby aktivni cislo faddr0 faddr1 faddr2

Typ SERIAL INTEGER INTEGER doklady typy platby typy BOOLEAN VARCHAR(16) VARCHAR(126) VARCHAR(64) VARCHAR(64)

Null NO NO YES NO NO YES YES YES YES YES

Default

true

56

KAPITOLA 5. NÁVRH A IMPLEMENTACE Key

FK

Název faddr3 fstat dt vystaveni dt dph dt splatnost cena cena dph text id uzivatele

Typ VARCHAR(8) VARCHAR(32) TIMESTAMP DATE DATE DECIMAL(8,2) DECIMAL(8,2) VARCHAR(1024) TIMESTAMP

Null YES YES NO YES YES NO NO YES NO

Default

CURRENT TIMESTAMP

Tabulka hlediste obsahuje seznam povolených hledišť, včetně jejich parametrů. Tabulka 5.16: Databázová tabulka: hlediste Key

Název id hlediste nazev kod src max s max m popis aktivni

Typ SERIAL VARCHAR(32) VARCHAR(8) VARCHAR(32) INTEGER INTEGER VARCHAR(128) BOOLEAN

Null NO NO NO NO NO NO YES NO

Default

0 0 true

Tabulka hledistesedadla popisuje jednotlivá sedadla v hledisti. Sedadlo může být identifikováno podle třech parametrů: sektoru a dvou volitelných parametrů pozice (např. řada, číslo). Z důvodu variability jsou tyto parametry konfigurovatelné (a, b), jejich textový popis je uložen v tabulce hledistesektory. Tímto je zajištěno, že část sedadel může mít např. řadu a číslo a druhá část číslo lóže a číslo sedadla. Tabulka 5.17: Databázová tabulka: hledistesedadla Key PK,FK PK FK

Název id hlediste id sedadla id sektoru a b extra poradi

Typ INTEGER INTEGER INTEGER VARCHAR(8) VARCHAR(8) VARCHAR(32) INTEGER

Null NO NO YES YES YES YES NO

Default

0


57

Tabulka hledistesektory popisuje jednotlivé sektory v hledišti a definuje parametry pozic pro tabulku hledistesedadla (a txt, b txt). Tabulka 5.18: Databázová tabulka: hledistesektory Key PK FK

Název id sektoru id hlediste nazev a txt b txt

Typ SERIAL INTEGER VARCHAR(64) VARCHAR(16) VARCHAR(16)

Null NO NO NO YES YES

Default

Tabulka hry obsahuje definici her (titulů) v systému. Atribut repertoar určuje, zda se hra pravidelně opakuje nebo se jedná o pouze jednu reprízu. Tabulka 5.19: Databázová tabulka: hry Key PK

Název id hry nazev popis aktivni repertoar

Typ SERIAL VARCHAR(64) VARCHAR(128) BOOLEAN BOOLEAN

Null NO NO YES NO NO

Default

true false

Tabulka hrydata obsahuje volitelné údaje o hře, je použito schéma klíč-hodnota. Tabulka 5.20: Databázová tabulka: hrydata Key FK FK

Název id hry klic hodnota

Typ INTEGER VARCHAR(16) VARCHAR(64)

Null NO NO NO

Default

Vazební tabulka hrytypy obsahuje seznam, jakých typů je daná hra. Tabulka 5.21: Databázová tabulka: hrytypy Key FK FK

Název id hry id typu

Typ INTEGER INTEGER

Null NO NO

Default

58


Tabulka kontakty je určena pro ukládání zákazníků. Každý zákazník může být přiřazen k jedné cenové kategorii a může mu být přeřazeno unikátní identifikační číslo UID. Tabulka 5.22: Databázová tabulka: kontakty Key PK FK

Název id kontaktu id kategorie uid titul jmeno prijmeni organizace ico dic addr0 addr1 addr2 addr3 stat faddr0 faddr1 faddr2 faddr3 fstat tel1 tel2 telf email banka1 banka2 poznamka

Typ SERIAL INTEGER VARCHAR(16) VARCHAR(16) VARCHAR(32) VARCHAR(64) VARCHAR(64) VARCHAR(16) VARCHAR(16) VARCHAR(126) VARCHAR(64) VARCHAR(32) VARCHAR(8) VARCHAR(32) VARCHAR(126) VARCHAR(64) VARCHAR(64) VARCHAR(8) VARCHAR(32) VARCHAR(32) VARCHAR(32) VARCHAR(32) VARCHAR(126) VARCHAR(64) VARCHAR(32) VARCHAR(4096)

Null NO YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES

Default

Tabulka platby obsahuje všechny uskutečněné finanční transakce. Z této tabulky jsou následně vypočítávány pokladní uzávěrky a statistiky. Atribut smer určuje, zda se jedná o platby příchozi nebo odchozí, typ platby určuje formu úhrady (například karta, hotovost). Tabulka 5.23: Databázová tabulka: platby Key PK FK

Název id platby id zakazky

Typ SERIAL INTEGER

Null NO NO

Default

5.1. FYZICKÝ DATOVÝ MODEL Key

FK

Název aktivni smer typ dt platby cena vs id uzivatele

59

Typ BOOLEAN platby smery platby typy DATE DECIMAL(8,2) VARCHAR(16) INTEGER

Null NO NO NO NO NO YES NO

Default true

CURRENT DATE

Tabulka pracoviste zavádí umístění uživatele, uživatelé mohou pracovat na více pracovištích, vždy však aktuálně pouze na jednom. V rámci práce na jednom pracovišti jsou ukládány parametry nastavení systému (především parametry tisku - volba tiskáren). Při změně pracoviště je nastavení obnoveno do stavu, ve kterém bylo v rámci daného pracoviště naposledy pracováno. Tabulka zavádí pojmenování pracovišť. Tabulka 5.24: Databázová tabulka: pracoviste Key PK

Název id pracoviste nazev aktivni

Typ SERIAL VARCHAR(32) BOOLEAN

Null NO NO NO

Default

true

Tabulka predstaveni obsahuje čas a hru, která je v akci konána. Akce může obsahovat více představení, tzn. že během živostnosti akce je možné změnit čas a hru, změna je ale v systému uchována a tím je zajištěna historie změn a přesunů jednotlivých akcí. Tabulka 5.25: Databázová tabulka: predstaveni Key PK FK FK

Název id predstaveni id akce id hry cas

Typ SERIAL INTEGER INTEGER DATETIME

Null NO NO NO NO

Default

Tabulka prodeje obsahuje záznamy o jednotlivých prodejích. Prodej je zde definován jako jedno prodané sedadlo. Po uskutečnění prodeje (zaplacení) je možné k prodanému sedadlu vygenerovat vstupenku, příp. duplikáty vstupenek. V prodeji je uložena případná sleva (id slevy) a výchozí cena, ze které byla cena konečná vypočtena (cenax).

60

KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.26: Databázová tabulka: prodeje Key PK FK FK

FK FK

Název id prodeje id zakazky id predstaveni id sedadla aktivni cenax cena cena dph dph typ id slevy id uzivatele dt

Typ SERIAL INTEGER INTEGER INTEGER BOOLEAN DECIMAL(8,2) DECIMAL(8,2) DECIMAL(8,2) SMALLINT INTEGER INTEGER TIMESTAMP

Null NO NO NO NO NO NO NO NO NO YES NO NO

Default

true

0

CURRENT TIMESTAMP

Tabulka rezervace obsahuje informace o rezervacích. Rezervace je skupina sedadel rezervovaných na jméno (atribut jmeno). U rezervace je možné nastavit datum vypršení (dt vyprseni). Na záznam v tabulce rezervace odkazují záznamy v tabulce rezervaced, což jsou jednotlivá sedadla, patřící k dané rezervaci. Tabulka 5.27: Databázová tabulka: rezervace Key PK FK

FK

Název id rezervace id predstaveni jmeno dt vyprseni poznamka aktivni pocet cena cena dph id uzivatele dt

Typ SERIAL INTEGER VARCHAR(32) TIMESTAMP VARCHAR(255) BOOLEAN INTEGER DECIMAL(8,2) DECIMAL(8,2) INTEGER TIMESTAMP

Null NO NO

NO NO NO NO NO NO

Default

true

CURRENT TIMESTAMP

Tabulka rezervaced obsahuje jednotlivá sedadla patřící rezervaci určené v id rezervace. Tabulka 5.28: Databázová tabulka: rezervaced Key PK,FK FK

Název id rezervace id sedadla cenax

Typ INTEGER INTEGER DECIMAL(8,2)

Null NO NO NO

Default

5.1. FYZICKÝ DATOVÝ MODEL Key

Název cena cena dph id slevy aktivni

61 Typ DECIMAL(8,2) DECIMAL(8,2) INTEGER BOOLEAN

Null NO NO YES NO

Default

true

Tabulka role obsahuje seznam všech uživatelských rolí v systému. Jednotlivá privilegia jsou uložena v tabulce roleopravneni. Tabulka 5.29: Databázová tabulka: role Key PK

Název id role nazev popis

Typ SERIAL VARCHAR(32) VARCHAR(64)

Null NO NO YES

Default

Tabulka roleopravneni obsahuje jednotlivá oprávnění (privilegia), tzn. názvy funkcí, které je možné v rámci dané role (dle id role) zavolat. Tabulka 5.30: Databázová tabulka: roleopravneni Key PK,FK PK

Název id role opravneni

Typ INTEGER VARCHAR(64)

Null NO NO

Default

Tabulka sabonma obsahuje storno záznam legitimace. Vzhledem k tomu, že je možné stornovat část legitimace (odehrané návštěvy se nestornují), obsahuje tato tabulka informace o ceně. Atribut id abonma odkazuje na původní legitimaci a id dokladu na patřičný storno doklad. Tabulka 5.31: Databázová tabulka: sabonma Key PK FK FK FK

FK

Název id sabonma id zakazky id dokladu id abonma cena cena dph dph typ id uzivatele dt

Typ SERIAL INTEGER INTEGER INTEGER DECIMAL(8,2) DECIMAL(8,2) SMALLINT INTEGER TIMESTAMP

Null NO NO YES NO NO NO NO NO NO

Default

0 CURRENT TIMESTAMP

62


Tabulka sabonmad je analogická k tabulce sabonma. Opět se jedná o storno záznamy, zde však jedné návštěvy v rámci předplatného. Tabulka 5.32: Databázová tabulka: sabonmad Key PK FK FK FK FK

Název id sabonmad id zakazky id dokladu id abonmad id uzivatele dt

Typ SERIAL INTEGER INTEGER INTEGER INTEGER TIMESTAMP

Null NO NO YES NO NO NO

Default

CURRENT TIMESTAMP

Tabulka slevy obsahuje seznam všech nadefinovaných slev v systému. Tyto slevy je poté možné povolovat pro jednotlivé akce (tabulka akceslevy). Slevy mají 2 parametry: k a q, výpočet ceny je prováděn pomocí lineární rovnice cenaf inal = k ∗ cena + q. Tabulka 5.33: Databázová tabulka: slevy Key PK

Název id slevy nazev aktivni k q

Typ SERIAL VARCHAR(32) BOOLEAN DECIMAL(5,2) DECIMAL(8,2)

Null NO NO NO NO NO

Default

true 1 0

Tabulka sprodeje zavádí storno položky pro prodané sedadlo. Jedná se opět o analogii k tabulkám sabonma a sabonmad. Atribut id prodeje odkazuje na původí prodej. Tabulka 5.34: Databázová tabulka: sprodeje Key PK FK FK FK FK

Název id sprodeje id zakazky id dokladu id prodeje id uzivatele dt

Typ SERIAL INTEGER INTEGER INTEGER INTEGER TIMESTAMP

Null NO NO YES NO NO NO

Default

CURRENT TIMESTAMP


63

Tabulka uzivatele obsahuje všechny registrované uživatele systému. Každému uživateli je přiřazena jedna uživatelská role a výchozí pracoviště, které je použito, pokud při přihlašování uživatel žádné nezvolí. Atribut persistentni sid je využíván u speciálních typů uživatelů, tzv. virtuálních. Tito uživatelé jsou de-facto roboti komunikující se systémem (např. jiné vstupenkové systémy). Persistentní SID zajišťuje, že tito roboti mají po přihlášení stejné ID sezení (session). Tito uživatelé se k systému připojují často a pokud by se při každém přihlášení generovalo nové ID sezení, vedlo by to ke zbytečné režii. Tabulka 5.35: Databázová tabulka: uzivatele Key PK FK

FK

Název id uzivatele id role auth name auth pass jmeno aktivni id pracoviste persistentni sid

Typ SERIAL INTEGER VARCHAR(32) VARCHAR(32) VARCHAR(32) BOOLEAN INTEGER BOOLEAN

Null NO NO NO NO YES NO NO NO

Default

true false

Tabulka vstupenky obsahuje všechny vygenerované vstupenky v systému. V případě tisku duplikátu vstupenky, je původní vstupenka deaktivována (stává se neplatnou) a je vygenerována nová vstupenka s novým číslem (id vstupenky) s nastaveným atributem duplikat. Vstupenka může mít též vygenerován unikátní čárový kód (barcode). Tabulka 5.36: Databázová tabulka: vstupenky Key PK FK

FK

Název id vstupenky id prodeje barcode aktivni duplikat id uzivatele dt

Typ SERIAL INTEGER VARCHAR(10) BOOLEAN BOOLEAN INTEGER TIMESTAMP

Null NO NO YES NO NO NO NO

Default

true false CURRENT TIMESTAMP

Tabulka zakázky obsahuje všechny zakázky zpracované systémem. Zakázka je seskupení vstupenek a legitimací, které je prodáno a vyfakturováno najednou zákazníkovi. Zakázky je možné částečně stornovat (např. po vstupenkách - prodejích). Speciálním typem zakázky je košík, což je zakázka, která má atribut cislo NULL. Košík lze libovolně upravovat.

64

KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.37: Databázová tabulka: zakazky Key PK FK

FK

5.1.2

Název id zakazky id kontaktu cislo stav cena cena dph zaplaceno stornovano id uzivatele dt vytvoreni

Typ SERIAL INTEGER VARCHAR(10) zakazky typy DECIMAL(8,2) DECIMAL(8,2) DECIMAL(8,2) DECIMAL(8,2) INTEGER TIMESTAMP

Null NO YES YES NO NO NO NO NO NO NO

Default

kosik 0 0 0 0 CURRENT TIMESTAMP

Uložené procedury

Významná část funkčnosti systému je prováděna v uložených procedurách. Zde je uveden seznam těch nejdůležitějších uložených procedur. Procedury jsou napsány v jazyce PL/pgSQL. • abonma create() Tato procedura slouží k vytvoření předplatitelské legitimace. Výsledkem je 1 záznam v tabulce abonma a počet záznamů v tabulce abonmad podle počtu návštěv v daném typu předplatného. Při vytváření je dynamicky vypočtena konečná cena legitimace podle výchozích cen v akcích a parametrů návštěv, příp. nastavena dle zvolené slevy u volného předplatného. • abonma premisteni() Tato procedura slouží ke změně sedadla u fixní předplatitelské legitimace. Místa, která byla obsazena u již odehraných akcí zůstanou beze změny, v neodehraných akcích jsou místa změněna. Procedura neřeší případnou změnu ceny při přesunu na sedadlo jiné cenové kategorie. • akce template() Tato procedura slouží ke kopírování akcí, kdy je zvolená akce brána jako šablona pro tvorbu akce nové. Překopírováno je nastavení cen, blokací, příp. typů a dat. • akced init() Tato procedura zajišťuje vygenerování správného počtu sedadel do zvoleného hlediště. • kosik del polozka() kosik delete() Tyto procedury slouží k odstranění položky / celého košíku. • kosik get() Tato procedura slouží k získání košíku zvoleného uživatele.


65

• make doklad() Tato procedura slouží vytvoření účetního dokladu. Pokud není proceduře předán typ dokladu, je zvolen automaticky podle vybraného typu platby. V případě, že je vytvořena faktura nebo prodejka, je zakázka, ke které doklad patří uzavřena (nelze ji dodatečně měnit bez řádného vystavení storno dokladů. • make prodej() Tato procedura slouží k rychlému prodání obsahu košíku (v systému vedeno jako vytvoření zjednodušené zakázky). Při tomto vytváření není možné přiřadit zakázce zákazníka, tudíž je prodáváno anonymnímu zákazníkovi. Tato procedura je využívána při prodeji na pokladně, kde je primárním úkolem co nejrychlejší odbavení zákazníků. • make rezervace() Tato procedura zajišťuje vytvoření rezervace z košíku. Vzhledem k tomu, že rezervace může být pouze na jednu akci, je vytvořeno tolik akcí, kolik různých akcí je v košíku. • make zakazka() Tato procedura slouží k vytvoření zakázky z košíku. Vzhledem k tomu, že košík je de-facto zakázka, tvorba zakázky spočívá v přidělení čísla zakázky (košík číslo nemá) a dodatečné kontrole parametrů. • prodej prepare() prodej add() prodej addzona() prodej complete() Tyto procedury slouží přidávání nebo editaci prodaných sedadel v košíku. Funkce prepare zajistí přípravu pro editaci/přidání. Pro každé sedadlo, resp. cenovou zónu u neadresních míst je volána procedura add, resp. addzona. Na konec je zavolána procedure complete, která editaci/přidání dokončí a provede úklid. • rezervace prepare() rezervace add() rezervace complete() Tyto procedury slouží k přidávání a editaci rezervace, jejich použití je analogické k prodaným sedadlům, pro podrobnější popis odkazuji na odstavec výše • rezervace kosik() Tato procedura slouží k uložení rezervace do košíku. Původní rezervace je zrušena a v košíku je vytvořen prodej sedadla • storno polozka() storno polozka abonma() storno polozka grupa() storno polozka prodej() Tyto procedury zajišťují stornování části (položek) zakázky/košíku. Storno polozka je nadrazena procedura ostatním, volána je pouze tato procedura, ostatní procedury jsou z této volány na základě typu položky. • zakazka pay() Tato procedura slouží k zaplacení zakázky. V tabulce platby je vytvořena adekvátní položka za uskutečněnou transakci.

66

KAPITOLA 5. NÁVRH A IMPLEMENTACE • zakazka polozky() Tato pomocná procedura vrací naformátovaný seznam položek v zakázce. Procedura byla vytvořena pro jednodušší načítání seznamu. • zakazka prodej() Tato procedura slouží k prodeji zakázky, tzn. zaplacení a vytvoření účetního dokladu podle typu platby. • zakazka storno() Tato procedura slouží ke stornování celé zakázky. • zakazka storno sum() Tato procedura slouží k mezivýpočtu ceny všech stornovaných položek zakázky. Je volána z funkcí určených k částečnému stornování zakázky. • zakazka storno prepare() zakazka storno polozka() zakazka storno complete() Tyto procedury oproti zakazka storno zajišťují částečné stornování zakázky. Prepare připraví položky ke stornování, polozka stornuje jednu vybranou položku a complete zajistí dokončení storna a úklid.

5.2

Popis komponent

Jak již bylo nastíněno v úvodní studii, aplikační vrstva je složena s několika komponent. Všechny funkce systému jsou seskupeny do modulů (dle jejich zaměření) a jednotlivé funkce jsou volány jako metody daného modulu pomocí JSON-RPC, protokolu vzdáleného volání procedur zakódovaný do JSON objektu. Jádro systému jako takové neobsahuje GUI1 . Pro tento účel byla vybrána JavaScriptová knihovna Ext JS, o poskytování potřebných dat se starají JsServlet a PkgServlet. Vzhledem k tomu, že systém není přímo svázán s žadným uživatelským rozhranním, je možné dle požadavků vytvořit vlastní řešení, příp. integrovat systém do již stávajících informačních systémů. Zdrojové kódy systému je tedy možné rozdělit na jádro systému a podporu GUI napsané v jazyce Java s využitím Java Servlets technologie a na GUI napsané v jazyce JavaScript. Nyní se blíže podíváme na jednotlivé komponenty.

5.2.1

Package cz.comnet.gemini

Tento package obsahuje základní třídy a jádro systému. Nalezneme zde především Servlety zajišťující podporu RPC protokolu. Těchto Servletů je několik a blíže se s nimi seznámíme v následujícím seznamu vybraných tříd. • Cron Třída starající se o pravidelné (konfigurovatelné) spouštění Java metod a SQL funkcí. Perioda spouštění je uživatelsky definovatelná. 1

Grafické uživatelské rozhranní

5.2. POPIS KOMPONENT

67

• Gemini Hlavní třída aplikace. Zajišťuje inicializaci a ukončování systému, dále obsahuje třídu pro aktualizaci databáze (DBUpdater). Třída DBUpdater kontroluje verzi databáze s verzí systému a v případě, že má databáze nižší verzi, pomocí uložených aktualizačních skriptů provede automatickou aktualizaci databázových tabulek a uložených procedur. • GPS Třída starající se o správu tisku. • GPSServlet Servlet zajišťující podporu pro GPS Servery. Podporuje registraci, stahování uloh včetně resource souborů a potvrzování úspěšnosti tisku. • GUIFilter Filtr starající se o přesměrování na správné GUI. • RPCArgNames RPCDesc Interface pro vlastní annotace zajišťující popis metod modulů a seznam parametrů. • RPCMapData Rozšířená třída HashMap pro manipulaci s parametry metod jednotlivých modulů. • RPCMethod RPCModule Třídy obalující moduly systému a jejich metody. • RPCServletData Servlet zajišťující poskytování dat dle content-type. Tento servlet je možné využít např. pro stahování ZIP exportních souborů nebo obrázků (resource souborů pro GPS Server) vrácených RPC funkcemi. • RPCServletJSONRPC Servlet zajišťující vzdálené volání procedur protokolem JSON-RPC. Po zahájení komunikace zajistí autentifikaci, ze získaného dotazu vyhodnotí volaný modul a metodu, zavolá ji a vrátí naformátovaný výsledek. • RPCServletXSLT Servlet starající se o XSL (volitelně XSL-FO) transformaci dat vrácených RPC funkcemi. Po zahájení komunikace zajistí autentifikaci. • RPCSession RPCSessionManager Třídy starající se o správu session uživatelů. Zajišťují jejich ukládání do databáze, příp. jejich načtení, platnost přihlášení a také ověřují oprávnění ke spuštění požadované metody modulu.

5.2.2

Package cz.comnet.gemini.cronlib

Do tohoto package patří všechny třídy, které je možné volat z třídy Cron.

68


5.2.3

Package cz.comnet.gemini.guiext2

Tento package zajišťuje podporu GUI systému. Vzhledem k tomu, že je pro GUI využita JavaScriptová knihovna Ext JS, je potřeba zajistit mechanismus pro získání potřebných .js souborů. O to se starají dva Java Servlety PkgServlet a JsServlet. Proč jsou tyto servlety dva zjistíme v další kapitole popisující GUI. • AuthFilter Filtr starající se o zajištění přihlášení pomocí HttpSession a následné předávání sid (Session ID) servletům, které jej vyžadují • JsServlet Servlet zajišťující odesílání požadovaných .js souborů • MenuBuilder Třída zajišťující tvorbu Menu pro GUI. Jednotlivé položky jsou do menu vkládány dle oprávnění přihlášeného uživatele (každý uživatel má dle oprávnění vlastní menu) • PkgServlet Servlet zajišťující odeslání základního HTML dokumentu s importem potřebných .js souborů (jejich odesílání zajišťuje JsServlet).

5.2.4

Package cz.comnet.gemini.modules

V tomto package jsou obsaženy jednotlivé moduly systému. Každá třída obsahuje metody, které je možné volat pomocí JSON-RPC mechanismu, pomocí annotací je u každé metody uložen seznam parametrů a popis metody. Každý modul systému zajišťuje určitý okruh operací. Ve správě systému je možné moduly dynamicky načítat nebo uvolňovat. • Abonma Modul pro podporu předplatitelských legitimací. Obsahuje funkce pro správu a vytváření legitimací, definici typů a cenových zón, dále pro přemístění sedadla v rámci legitimace, získání detailu legitimace, aj. • Adresar Modul pro správu zákazníků. Obsahuje funkce pro správu databáze zákazníků, včetně správy cenových kategorií zákazníků (např. stálý zákazník, VIP, atd.) • Akce Modul pro správu akcí a představení. Obsahuje funkce pro zakládání, editaci a kopírování akcí, dále pro správu typů a dat akcí. Další funkce zajišťují např. detail akce, aj. • Blokace Modul pro správu blokací. Obsahuje funkce pro přidávání, editaci a mazání blokací, včetně přiřazování uživatelů k blokacím. • Cron Modul pro správu cron úloh.

5.2. POPIS KOMPONENT

69

• Doklady Modul pro správu všech dokladů v systému. Obsahuje funkce pro čtení a editaci dokladů. • Gps Modul pro správu tiskového subsystému. Obsahuje funkce pro správu tiskáren a GPS Serverů. Dále zajišťuje správu tiskových šablon a resource souborů pro GPS Servery. V neposlední řadě zajišťuje vytváření jednotlivých tiskových úloh včetně XSL transformace. • Hlediste Modul pro správu hledišť (adresních i neadresních) • Hry Modul pro správu her. Obsahuje funkce pro přidávání, editaci a mazání her, dále pro správu typů a dat her. • Kosik Modul pro správu nákupního košíku. Obsahuje operace pro vytvoření zakázky z košíku, vytvoření rezervace a prodej košíku. Další funkce zajišťují správu položek košíku, včetně jeho kompletního vymazání. • Log Modul pro zajištění přístupu k systémovému logu. • Moduly Modul pro zajištění správy modulů. Zajišťuje funkce pro výběr modulů, které jsou v systému aktivní. • Pracoviste Modul pro správu pracovišť • Prodeje Modul pro správu prodejů - prodaných sedadel. Obsahuje funkce pro vložení sedadel do košíku a manipulaci se vstupenkymi, včetně jejich stornování po jednotlivých vstupenkách. • Rezervace Modul pro správu rezervací. Obsahuje funkce pro editaci, mazání a vkládání rezervací do košíku. • Role Modul pro správu uživatelských rolí v systému. • Servis Modul pro servisní účely. Obsahuje funkce pro podporu SQL konzole a vzdáleného restartu systému. • Session Modul zajišťující přihlašování a odhlašování uživatelů do/z systému. • Slevy Modul pro správu slev. Obsahuje funkce pro přidávání, editaci a mazání pojmenovaných slev.

70

KAPITOLA 5. NÁVRH A IMPLEMENTACE • Statistika Modul zajišťující statistické výstupy ze systému. • Uzivatele Modul pro správu uživatelů systému. • WebTicket Modul zajišťující podporu systému WebTicket (systém internetových rezervací a prodejů) • Zakazky Modull pro správu zakázek. Obsahuje funkce pro prodej a stornování zakázky, včetně její editace a editace jejich položek.

5.3

GUI

Pro grafické uživatelské rozhranní je využita knihovna Ext JS, pro zobrazení hledišť SVG. Veškeré zdrojové kódy jsou uloženy v /src/main/webapp/gui_ext2. Struktura adresáře je tato: • css Zde jsou uloženy kaskádové styly a obrázky používané v GUI • lib Zde jsou uloženy knihovny grafických prvků systému. Každé okno (dialog) nebo seznam je uložen v samostaném .js souboru. • pkg Zde jsou uloženy JavaScriptové „JSBalíčkyÿ. JSBalíčkem je seskupení potřebných knihoven grafických prvků tvořících GUI. • svg Zde jsou uloženy SVG zdrojové kódy hledišť komprimované metodou GZIP. Dostáváme se k tématu proč JSBalíčky (potažmo proč JsServlet a PkgServlet). Knihovna Ext JS je graficky velmi pěkná a uživatelsky přívětivá. Bohužel to s sebou nese vysoké požadavky na výkon JavaScriptového interpreteru v prohlížeči a především má vysoké nároky na paměť. Vzhledem k velikosti aplikace není možné celé GUI nahrát do prohlížeče jako jeden balík. Takto obsáhlý JavaScriptový kód vede k zaplnění paměti a výraznému zpomalený pod hranici použitelnosti. Idea je tedy taková, že systém rozdělíme do samostatných funkčních bloků. Například blok pro prodej obsahuje adresář, seznam akcí, rezervací a zakázek. Během běžného prodeje uživatel pracuje pouze s těmito částmi systému a je proto vhodné je seskupit do JSBalíčku, který je nahrán najednou. Pokud uživatel požaduje jinou funkci systému, než která je v něm obsažena, je nahrán jiný balíček. Nahrávání balíčku se časově náročnější (nahrávání kódu a inicializace), nicméně vhodným zvolením seskupení je toto nahrávání prováděno v časově nekritických místech systému. Na této myšlence je postaven systém JSBalíčků a knihoven. Každý JSBalíček obsahuje popis celé HTML stránky systému, včetně seznamu používaných knihoven a možných

5.4. GEMINI PRINT SERVER

71

oprávnění. PkgServlet tento balíček načte, připojí k němu požadované knihovny, provede optimalizaci a výsledek odešle prohlížeči. Každý JSBalíček obsahuje na začátku dokumentu metadata, podle kterých se výsledný balík zkonstruován. // // // // // // // // // //

GEMINI METADATA import gemini.Menu import gemini.sprava.Akce import gemini.sprava.Hry import gemini.sprava.Slevy import gemini.sprava.Blokace import ext-ux.MultiPagePanel menu 990010 "Správa|Správa akcí" /pkg/sprava/akce#akce akce.getList menu 990011 "Správa|Správa her" /pkg/sprava/akce#hry hry.getList END

Sekce import zajistí vložení knihovny do balíčku. Sekce menu přidá do menu položku definovanou číslem, názvem a privilegiem. Pokud uživatel nemá požadované privilegium, položka v menu není zobrazena.

5.4

Gemini Print Server

GPS (Gemini Print Server) je malá JAVA aplikace, která zajišťuje tisk na tiskárnách klientů. Vzhledem k tomu, že je GEMINI webová aplikace, klienti mohou přistupovat ze sítí, které jsou napříkad NATovány, není možný přímý tisk ze systému. GPS běží na pozadí na počítačích, ke kterým jsou tiskárny připojené (může to být ale i server se síťovými tiskárnami) a sleduje, zda není v GEMINI nová úloha k vytištění na některé z tiskáren k němu připojených. V případě nalezení nové úlohy je tato následně stažena. Ze serveru GPS stahuje XML data tisku. Tato data obsahují též XSL/-FO šablonu, která je také stažena a použita k překladu XML dat. Pokud data obsahují odkaz na grafický resource (obrázek), je během překladu stažen ze serveru GEMINI a uložen do cache pro případné další použití. Přeložený výsledek je poté odeslán na tiskárnu. GPS umí pro definici tisku použít více jazyků. Z tohoto důvodu GPS obsahuje tiskové ovladače. Při konfiguraci GPS je u každé tiskárny uveden tiskový ovladač, který bude použit. V současnosti je možné použít XSL-FO (ovladač JavaFO) nebo jazyk GPS (ovladač JavaGPS). Ovladač JavaFO používá standardní mechanismus překladu XSL-FO. Ovladač JavaGPS používá speciální interní značkovací jazyk pro popis tisku. Tisknout je možné základní entity: text, čáry, čárové kódy a obrázky. Jazyk především obsahuje podporu pro tisk opakujících se objektů a tím zásadně snižuje komunikační režii s GEMINI. Jazyk byl primárně vytvořen pro definici tisku vstupenek, lze ale úspěšně použít pro tisk legitimací nebo adresních štítků. Popis jazyka je uveden na příkladu tisku vstupenek. Vstupenky jsou tištěny po skupinách, po akcích. Tato skupina vstupenek využije element group. V rámci této skupiny jsou na vstupenky tištěny některé shodné údaje, např. název akce, místo konání. Pro tyto položky je určen element common, položky v tomto elementu se vkládají do každé vstupenky (elementu item). Nakonec je element item, což je popis jedné vstupenky, zde vložíme položky, které jsou na každé vstupence jiné (např. cena, misto).

72 ...


Kapitola 6

Testování Testování je je jedním z nejdůležitějších částí životního cyklu vývoje aplikací. Slouží k zajištění požadované kvality softwarového produktu. Testy jsou rozděleny do několika částí.

6.1

Testování kódu

Při testování kódu se snažíme přivést testovaný systém do nestandardního stavu. Tohoto stavu se snažíme docílit zadáváním pokud možno takovým počtem vstupních kombinací, aby bylo pokryto co nejvíce možností vstupních dat v reálném provozu. Testování kódu je vhodné provádět již během vývoje jednotlivých komponent. Zadáním vstupních dat do aplikace získáme vzorek výstupních dat, která jsou následně porovnána s očekávanými hodnotami. Pokud se data neschodují, je vyniklá chyba zaznamenána a následně opravena. Pro generování vstupních dat se běžně používají dvě techniky - „white-boxÿ a „black-boxÿ testování.

6.1.1

white-box testování

White-box testování1 využívá pro tvorbu vstupních dat znalosti vnitřní struktury a logiky aplikace. Tento druh testování vyžaduje výbornou znalost aplikace testerem. White-box testování je především používáno na testování malých funkčních celků. White-box testování bylo prováděno výhradně mnou, jako řešitelem.

6.1.2

black-box testování

Black-box testování2 pohlíží na aplikaci jako na černou skříňku. Tester se zpravidla řídí naplánovaným scénářem standardních i nestandardních operací a porovnává očekávané výstupy se získanými. Black-box testování bylo prováděno jak ve společnosti ComNet, s.r.o., tak v Hudebním divadle Karlín a Moravském divadle Olomouc. Uživatelé po seznámení prováděli simulovanou zátěž systému, zjištěné nestandardní chování bylo reportováno a následně opraveno. Během testování uživatelé z řad divadel vznesli řadu nápadů na vylepšení systému, některé z těchto požadovaných vlastností bylo následně implementováno. 1 2

Někdy též nazýváno jako glass-box, clear-box, logic-driven testing Někdy též nazýváno jako functional, data-driven, input-output driven testing

73

74

6.2

KAPITOLA 6. TESTOVÁNÍ

Testování databáze

První fází testování je vlastní kontrola definic tabulek a jejich propojení, cizích klíčů a integritních omezení. Druhá fáze spočívá v naplnění databáze testovacími daty a následné kontrole výstupů ze sady testovacích SQL dotazů. Jedná se zejména o kontrolu nastavení a výpočtu všech atributů. Testovacími SQL dotazy byla též analyzována správnost algoritmů výpočtu statistik. Tyto výpočty jsou prováděny v uložených procedurách databáze.

6.3

Testování GUI

Testování uživatelského rozhranní obsahuje jak testování jednotlivých částí, tak testování GUI jako celku. V těchto fázích jsou testovány kontroly všech uživatelských vstupů a omezení proti zadávání neplatných hodnot. Dále bylo testováno rozvržení a umístění všech ovládacích prvků s ohledem na různé velikosti okna prohlížeče. V neposlední řadě byl testován vlastní výkon GUI, který je velmi závislý na výkonu JavaScriptového engine prohlížeče. Výsledkem těchto testů byly další optimalizace pro zlepšení výkonu GUI.

6.4

Usability testy

Usability testy byly prováděny s reálnými uživateli. Tito uživatelé byly vybráni z řad pokladních a referentek obchodních oddělení divadla. Tito uživatelé měli po krátkém seznámení se systémem provést definované úkony, průběh jejich práce byl zaznamenáván a následně vyhodnocován. Výsledkem těchto testů byla optimalizace uživatelského rozhranní, především přeuspořádání ovládacích prvků a doplnění vysvětlivek. Dalším zjištěním bylo, že díky stejné filozofii prodeje jako v internetovém obchodě je práce celkem intuitivní a přímočará a na učení uživatelů klade velmi malé nároky. Pro detailnější práci se systémem je ale potřeba hlubší studium terminologií, ve kterých se systém od konkurenčních produktů zásadně liší.

Kapitola 7

Závěr 7.1

Zhodnocení

Cílem práce bylo navrhnout a implementovat vstupenkový informační systém pro divadla. Po zhodnocení současného stavu na trhu jsem se rozhodl pro vlastní implementaci založenou na otevřených technologiích s důrazem na multiplatformitu. Pro získání potřebných informací bylo nutné problematiku důkladně analyzovat. V této fázi přípravy projektu jsem spolupracoval ze zástupci obchodních a technických oddělení vybraných divadel (Moravské divadlo Olomouc, Hudební divadlo Karlín), kteří mi poskytli množství podnětů pro výsledný informační systém. Výsledkem byla obsáhlá analýza, jejíž část je též zahrnuta v této práci. Využil jsem též své vlastní zkušenosti, především díky tomu, že v několika divadlech pracuji jako správce sítě a systémový administrátor. Po provedení analýzy jsem přistoupil k vlastní implementaci, kterou předcházelo intenzivní studium použitých technologií. Důležitou a nedílnou součástí práce bylo též vytvoření srozumitelné a přehledné uživatelské příručky, včetně instalačního manuálu. Největším přínosem práce bylo praktické seznámení s vhodnými nástroji pro analýzu projektu a prohloubení zkušeností s použitými technologiemi (především Java EE), včetně následné dokumentace. Již delší dobu jsem pro vývoj webových aplikací využíval skriptovací jazyk PHP1 , který je pro spoustu aplikací vhodný a výkonný, nicméně pro náročnější aplikace již jeho použití vhodné není. Jeho výhody jako např. netypovost se kriticky projeví v přehlednosti a robustnosti kódu. Tato práce byla vhodným impulzem k přechodu na novou a výkonnou technologii Java EE. Z této technologie byla v práci využita jen malá část, nicméně se jedná o první důležitý krok k dalšímu studiu.

7.2

Budoucnost

Systém je v současné verzi brán jako základ pro další rozšiřování. Každá organizace má své vlastní požadavky a je nutné systém personifikovat a upravovat. Díky modulární architektuře by tyto změny měly být jednoduché a především znovupoužitelné. 1

PHP - „Hypertext Preprocessorÿ je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek (http://cz.php.net)

75

76

KAPITOLA 7. ZÁVĚR

Navržený systém je též možné dále vylepšovat. Především je vhodné dále upravit správu hledišť. V současné verzi je hlediště dodáváno se systémem a zákazník může přidávat pouze hlediště neadresní, příp. použít některé z již vytvořených hledišť. Vhodným rozšířením by byla implementace rozhranní pro vlastní kreslení a generování hledišť. Tato funkce je však velice obsáhlá a do této práce se již nevešla.

Literatura [1] M. M. Hana Kanisová. UML srozumitelně. Computer Press, 2. aktualizované vydání, 2006. [2] S. Holzner. XSLT: příručka internetového vývojáře. Computer Press, 2002. [3] S. Holzner. Mistrovství v Ajaxu. Computer Press, 2007. [4] M. Šimůnek. SQL: Kompletní kapesní průvodce. Grada, 1999. [5] J. P. Ivan Halaška. Databázové systémy. Vydavatelství ČVUT, 2. vydání, 2003. [6] J. Kosek. HTML: tvorba dokonalých www stránek. Grada, 2003. [7] B. Momjian. PostgreSQL - Praktický průvodce. Computer Press, 2003. [8] J. Resig. JavaScript a Ajax. Computer Press, 2007. [9] B. Spell. JAVA: programujeme profesionálně. Computer Press, 2002. [10] Ext JS — oficiální stránka [online]. URL: . [11] K336 Info — pokyny pro psaní diplomových prací [online]. URL: . [12] Java servlets — seriál o technologii na serveru interval.cz [online]. URL: . [13] Java EE — oficiální stránka na serveru SUN [online]. URL: . [14] Jetty 6 — oficiální stránka na serveru mortbay.org [online]. URL: . [15] LATEX — online manuál [online]. URL: . [16] PostgreSQL — oficiální stránka databázového serveru [online]. URL: . [17] Scalable Vector Graphics (SVG) 1.1 specification [online]. URL: . [18] W3 Schools — xml tutorials, browser scripting [online]. URL: .

77

78

LITERATURA

Příloha A

Instalační příručka Instalace vstupenkového systému GEMINI sestává s několika fází. Před vlastní instalací je nezbytné, aby cílový počítač splňoval systémové požadavky uvedené níže. Nejprve je nutné na cílovém počítači nainstalovat podpůrné programy, poté přikročíme k vlastní instalaci systému. Vlastní instalace systému dále spočívá v instalaci serveru a potřebného počtu GPS serverů.

A.1

Minimální systémové požadavky

• CPU x86 kompatibilní, 1,5GHz • 512MB RAM (optimálně 1GB nebo více) • 300MB diskového prostoru (+ prostor pro data) • OS Windows 2000 nebo novější, Linux (kernel 2.6.18 nebo novější)

A.2

Instalace podpůrných aplikací

1. Instalace JRE1 6 Nainstalujte podporu pro běh aplikací JRE (verze Java SE), volně ke stažení na http://java.sun.com/javase/downloads/index.jsp nebo ve Vaší distribuci Linuxu. 2. Instalace PostgreSQL 8.3 Nainstalujte databázi PostgreSQL, volně ke stažení na http://www.postgresql.org/download/ nebo ve Vaší distribuci Linuxu.

A.3

Instalace serveru

1. Vytvořte si na pevném disku adresář pro program (Windows např. C:\gemini, Linux /opt/gemini. 2. Zkopírujte do vytvořeného adresáře soubory z CD z adresáře /dist/gemini/. 1

Java Runtime Environment

79

80

PŘÍLOHA A. INSTALAČNÍ PŘÍRUČKA 3. Vygenerujte certifikát pro server keytool -genkey -keyalg RSA -dname "cn=localhost, o=ComNet\, s.r.o., ou=Gemini, L=Prague, S=Czech Republic, C=CZ" -alias jetty -keypass xxx -keystore ./keystore -storepass xxx -validity 3650 kde za xxx u -keypass a -storepass zadejte vlastní hesla, místo cn=localhost můžete zadat vlastní doménu, na které systém poběží. Utilitu keytool naleznete ve Vaší distribuci JRE. Výsledný soubor keystore uložte do adresáře C:\gemini\etc (Win), resp /opt/gemini/etc (Linux). 4. Nakonfigurujte server V souboru etc/gemini.xml nastavte vybrané heslo pro keystore. V souboru etc/gemini-env.xml můžete měnit následující proměnné: • kod definuje kód systému (používáno při synchronizaci se systémem WebTicket), • name definuje název systému, • debug určuje, zda systém poběží v debugovacím režimu (např. nejsou odesílány chybové hlášení emailem), • session_lt nastavuje čas vypršení session při nečinnosti uživatele (automatické odhlášení). V sekci mail je možné nakonfigurovat odesílání chybových hlášení emailem. 5. Vytvořte databázi Spusťte jako uživatel postgres (Win), resp. root (Linux) dávkový SQL soubor install.sql uložený v adresáři C:\gemini\install (Win), resp. /opt/gemini/install (Linux). 6. Přejděte do adresáře C:\gemini (Win), resp. /opt/gemini (Linux) a spusťte systém příkazem start.bat (Win), resp. bin/start.sh (Linux). Systém si při prvním spuštění sám inicializuje databázi, případných chybových hlášení si během inicializace databáze nevšímejte. 7. Pod Windows je možné systém nainstalovat jako službu systému Windows, instalaci provedeme spuštěním příkazu Jetty-Service --install v adresáři C:\gemini. Spouštění a vypínání systému již poté můžete provést přes služby systému Windows. 8. Doplňte do databáze nastavení šablon Spusťte dávkový SQL soubor configure.sql uložený v adresáři C:\gemini\install (Win), resp. /opt/gemini/install (Linux).

A.4

Instalace GPS Serveru

1. Vytvořte si na pevném disku adresář pro program (Windows např. C:\gps, Linux /opt/gps. 2. Zkopírujte do vytvořeného adresáře soubory z CD z adresáře /dist/gps/.

A.4. INSTALACE GPS SERVERU

81

3. Nakonfigurujte GPS server, konfiguraci GPS serveru popisuje uživatelská příručka (kapitola 6). 4. Spusťte GPS Server příkazem gps.bat (Win), resp. gps.sh (Linux). 5. Pokud chcete ve Windows zjistit příčiny nenastartování GPS Serveru, spusťte jej příkazem gps_debug.bat. Tím spustíte GPS Server v konzoli, kde získáte potřebná chybová hlášení

82

PŘÍLOHA A. INSTALAČNÍ PŘÍRUČKA

Příloha B

Uživatelská příručka B.1

Úvod

Tento text je koncipován jako základní uživatelská příručka pro vstupenkový informační systém GEMINI společnosti ComNet, s.r.o. Základním úkolem systému „GEMINIÿ je zajištění distribuce vstupenek a předplatitelských legitimací na libovolné množství akcí pořádaných nebo zprostředkovaných majitelem systému v libovolném množství hledišť a následné statistické a účetní vyhodnocení prodeje. Informační systém je navržen jako webová aplikace typu Klient-Server. Pro přístup do systému je nutný pouze internetový prohlížeč s podporou zobrazení SVG (systém je bez SVG funkční, nicméně jeho funkčnost je omezena). Tato podpora může být buď přímo integrována v prohlížeči (Mozilla Firefox, Google Chrome, Opera) nebo jako plugin (Microsoft Internet Explorer). Prohlížeče musí mít zapnutou podporu JavaScriptu. Doporučený a testovaný prohlížeč je Mozilla Firefox 3.0 a Google Chrome. Pro podporu tisku vstupenek je potřebná podpora pro běh Java aplikací (JRE1 ) a dodaný jednoduchý program GPS (Gemini Print Server). Pro přihlášení do systému zadáváme do prohlížeče https://adresa:8443, kde za adresu uvedeme adresu serveru, na kterém systém běží (např. localhost).

B.1.1

Základní informace o systému

Systém používá ucelený vzhled v rámci celé aplikace. Okno aplikace je rozděleno do několika sekcí, které ilustruje obrázek B.1. V levé části (1) naleznete vždy Menu aplikace, které tvoří stromovou strukturu pro jednodušší hledání jednotlivých příkazů. V hlavní části (2) jsou vždy zobrazována data, se kterými aktuálně pracujete. V levé části (3), pokud je to možné, je vysouvací panel s filtry. Na stránkách spadajících pod sekci Prodej nalezneme v dolní části panel košíku (4). Vstupenky a legitimace jsou nejprve vkládány do košíku a poté je s nimi dále pracováno, systém pracuje na standardním principu eshopu. Nyní se podíváme na podrobnější popis jednotlivých sekcí. 1

Java Runtime Environment - podpora pro běh Java aplikací od společnosti Sun

83

84

PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA

Obrázek B.1: Hlavní okno aplikace

B.1.2

Filtry

Filtry slouží k omezení výpisu vybraného seznamu. Pokud je to možné, naleznete vždy filtr vpravo od hlavního okna. Panel filtru je zasouvací, pokud jej nepotřebujete, je možné si tím zvětšit prostor pro hlavní okno. Ve filtru naleznete 2 tlačítka: Výchozí a Použít. Tlačítko Výchozí slouží k nastavení filtru do výchozích hodnot. Toto tlačítko je nejvíce užitečné v situaci, kdy vyplníte filtr tak, že se Vám nezobrazují žádná data a chcete při vyhledávání začít od začátku. Jakmile změníte hodnotu filtru, tlačítko Použít se ztuční a tím signalizuje, že se filtr změnil. Pokud chcete filtr aplikovat na seznam, musíte ještě stisknout tlačítko Použít. Toto je nejčastější chyba uživatelů, kteří pouze vyplní filtr, ale již jej neodešlou.

B.1.3

Seznamy

Všechny seznamy v aplikaci mají konzistentní vzhled a funkčnost. V horní části seznamu pod titulkem obvykle naleznete toolbar s tlačítky pro práci se seznamem. Neaktivní tlačítka jsou šedivá, většina tlačítek (a operací) je vázána na jednotlivé řádky, po výběru daného řádku se požadovaná tlačítka zaktivní. Každý řádek může obsahovat kontextové menu, to vyvoláte kliknutím pravého tlačítky myši na vybraném řádku2 . Ve spodní části seznamu je stavová lišta seznamu. Informace v liště zobrazují počet záznamů v seznamu a pozice pohledu v seznamu. Pomocí tlačítek v liště můžete listovat 2

Kontextové menu vyvolávané stisknutím pravého tlačítka nemusí fungovat ve všech prohlížečích. V podporovaných prohlížečích Mozilla Firefox a Google Chrome je menu funkční

B.1. ÚVOD

85

Obrázek B.2: Seznam akcí v seznamech, jednotlivá tlačítka v seznamu zleva mají tuto funkčnost: posun na první stránku, posun vlevo, políčko na zadání stránky, posun vpravo, posun na poslední stránku, obnovení stránky. Seznamy je možné třídit podle jednotlivých sloupců. Kliknutím na vybraný sloupec je ten následně setříděn. Opětovným kliknutím je setříděn obráceně. Směr třídění je signalizován šipkou. Sloupce je možné přetahovat (měnit jejich posloupnost, stačí požadovaný sloupec uchopit myší a přetáhnout na jiné místo. Další operace se sloupci je možné provádět najetím myší na hlavičku sloupce a kliknutím na rozbalovací šipku pro získání kontextového menu. Zde v menu je možné například některé sloupce odstranit, případně přidat.

B.1.4

Menu

Obrázek B.3: Menu aplikace Menu aplikace je umístěno vždy vlevo. Tvoří stromovou strukturu, kde jsou jednotlivé části systému logicky seskupeny. Zobrazení položek v menu je ovlivněno oprávně-

86


ními pro daného uživatele, potažmo jeho role v systému. Hlavní rozdělení je na Prodej obsahující funkce potřebné pro prodej vstupenek a legitimací (Adresář, Zakázky, Doklady, . . .), Statistika obsahující veškeré statistické výstupy, Správa obsahující veškerou správu systému (Nasazování akcí, správa slev, blokací, uživatelů, atd.) a poslední Servis určení pro servisní nastavování systému.

B.2

Servis systému

Sekce servis systému slouží k nastavování parametrů systému a jeho správě. Tato sekce je určena pouze proškoleným administrátorům.

B.2.1

Správa modulů

Vstupenkový systém je rozdělen do funkčních celků - modulů. V této sekci je možné moduly aktivovat nebo deaktivovat. Nastavení má vliv na celý systém. Moduly jsou rozděleny do dvou kategorií: moduly systémové, které nelze odstranit (označeny hnědou barvou) a uživatelské.

B.2.2

Správa rolí

Přístup k funkčním částem systému je omezen přístupovými právy. Přístupové právo je v tomto případě chápáno jako povolení vykonat funkci systému (např. zobrazit seznam akcí, přidání uživatele, atd. . .). Těchto práv je v systému definováno veliké množství (pro každou operaci systému jedno) a pro byly vytvořeny Uživatelské role. Uživatelská role je pojmenované seskupení přístupových práv zajišťující okruh činností v systému (např. Administrátor, Prodejce vstupenek, Prodejce předplatitelských legitimací). V této sekci si můžete vytvořit libovolné množství uživatelských rolí a přiřadit k nim jednotlivá oprávnění.

Obrázek B.4: Dialog Editace oprávnění role V hlavním okně naleznete seznam uživatelských rolí. Tlačítkem Nová role založíte novou roli (POZOR: nová role nemá žádná oprávnění), tlačítkem Edituj roli měníte

B.2. SERVIS SYSTÉMU

87

název role, nikoliv její oprávnění, ty se nastavují v dialogu po stisknutí tlačítka Edituj oprávnění role. V dialogu Editace oprávnění role naleznete seznam všech oprávnění v systému seskupený podle modulů a zaškrtnutím patřičných kolonek přiřadíte požadovaná oprávnění.

B.2.3

SQL konzole

SQL konzole slouží pro pohodlné volání SQL dotazů přímo do databáze. Je možné volat obvyklé konstrukce SQL dotazu, systémové příkazy začínající \ nejsou podporovány.

B.2.4

Správa cronu

Správa cronu slouží ke správě pravidelně se opakujících operací v systému. Jako příklad je uvedeno pravidelné volání kontroly vypršení rezervací. V hlavní části vidíte seznam všech cron záznamů. Nový cron záznam vytvoříme přes tlačítko Nový cron záznam, příp. smažeme tlačítkem Smaž cron záznam. Při vytváření nového cron záznamu nebo editací (přes Edituj cron záznam) vyplňujeme následující dialog informací o cron zázamu.

Obrázek B.5: Dialog Editace cron záznamu Cronem může být vyvolána buď funkce systému z nějakého modulu (typ Java metoda) nebo může být vyvolán SQL příkaz (typ SQL příkaz ). V kolonce příkaz je nutné vyplnit buď název funkce nebo SQL příkaz. Každý cron záznam má vlastní prioritu, pokud je ve stejný čas voláno více záznamů najednou, jsou volány dle jejich priorit od nejnižší po nejvyšší. Dále je ještě nutné vyplnit interval mezi jednotlivými voláními. Volitelnými položkami jsou časy Tmin a Tmax, které omezují volání záznamu v rámci jednoho dne. Pokud např. chceme volat záznam pouze mezi 13. a 14. hodinou odpoledne, zadáme příslušné časy do volných kolonek. Dále můžete vyplnit volitelný popis pro vlastní potřebu. Poslední položkou je volba aktivní, pokud není záznam aktivní je dočasně pozastaveno jeho vykonávání

88


B.2.5

Systémový log

Důležité činnosti systému a případné chyby jsou logovány. Seznam těchto událostí je možné sledovat v sekci Systémový log. Logované události jsou rozřazeny podle úrovní (ERROR, WARNING, INFO, NOTICE a DEBUG) a je možné je dle rozmanitých možností vyhledávat.

B.2.6

GPS

GPS je interní zkratka pro Gemini Print Server. GPS zajišťuje veškerý tisk ze systému. Vzhledem k architektuře, kdy je vstupenkový systém provozován jako webová aplikace je zajištění automatického tisku problematické. Systém může například běžet ve Vaší organizaci a uživatelé pracují se systémem vzdáleně v jiném městě a navíc jsou připojeni k internetu přes zabezpečený router. Z toho příkladu je patrné, že vstupenkový systém nemůže přímo tisknout na tiskárnách uživatelů a proto je zde využíván tisk pomocí GPS. GPS je vlastně malá JAVA aplikace, která běží na pozadí počítačů, ke kterým jsou připojeny tiskárny pro tisk ze systému. Tato aplikace (budeme jí dále říkat GPSServer ) se spojí se vstupenkovým systémem a sleduje, zda nevznikl nějaký nový požadavek na tisk na tiskárnách připojených ke GPSServeru. Jak bylo již v předchozí větě naznačeno, k jednomu GPSServeru může být připojeno více lokálních i síťových tiskáren. GPSServer se k systému přihlašuje uživatelským jménem a heslem a odesílá informace o k němu připojených tiskárnách. O GPSServeru se více dozvíme v dalších kapitolách. B.2.6.1

Servery

V této sekci spravujeme všechny GPSServery, které se mohou k systému připojit. Každý server je jednoznačně identifikován názvem (tento název je pouze pro interní potřebu systému), zde nastavujeme přihlašovací jméno a heslo, kterým se autentifikují jednotlivé GPSServery. Pro dočasné zablokování některého GPSServeru je možné jej deaktivovat. GPSServery je možné přidávat (Nový server ), editovat (Edituj server ) a smazat (Smaž server ). B.2.6.2

Tiskárny

Zde se spravují všechny tiskárny, na které je možné ze systému tisknout. Tyto tiskárny jsou připojeny ke GPSServerům a tyto následně stahují tiskové úlohy pro připojené tiskárny. Každá tiskárna je identifikována svým názvem. Je nutné mít na paměti, že název tiskárny se MUSÍ shodovat s názvem tiskárny v konfiguraci GPSServeru (uvedeno dále v příručce)! Tímto vznikne spojení GPSServer-Tiskárna, které musí být konzistentní s konfigurací GPSServeru, jinak nebude tiskárna zaregistrována a nebude možné na ní tisknout. Vzhledem k rozmanitosti tiskových výstupů je potřeba zvolit jaký typ dokumentů bude na tiskárně tištěn. Při žádosti o tisk budou poté nabízeny pouze tiskárny k tomu určené. Typy dokumentů mohou být tyto: • dokumenty (faktury, prodejky, dobropisy)

B.2. SERVIS SYSTÉMU

89

• legitimace (předplatitelské legitimace) • vstupenky • kupóny • účtenky

Obrázek B.6: Dialog Editace tiskárny Dále je potřeba zvolit GPS Šablonu pro formátování tisku. GPS Šablona je šablona určující rozložení tisknutých dokumentů na jednotlivé stránky. K čemu je to dobré? Například když budeme tisknout vstupenky na arch A4, kde je předtištěno 5 vstupenek. GPS Šablona zajistí, že budou vstupenky naformátovány tak, že se jich vytiskne všech 5 na jeden arch. Poslední volba Potvrzuj tisk slouží k zobrazení dialogu pro potvrzení před odesláním tiskové úlohy (slouží například k čekání na založení papíru do tiskárny). Volba aktivní umožňuje dočasně tiskárnu deaktivovat. B.2.6.3

Šablony

Zde je možné spravovat všechny tiskové šablony. Šablony mohou být psány v jednom z těchto jazyků: GPS, XSLT a XSL-FO. Všechno jsou to transformační šablony a využívají XSL transformaci. Jazyk GPS je speciální interní značkovací jazyk pro tisk textů, čar, čárových kódů a vkládání obrázků. Tento jazyk je využíván pro formátování vstupenek a legitimací. Šablony je možné přídávat (Nová šablona), editovat (Editace šablony) nebo smazat (Smaž šablonu). B.2.6.4

Úlohy

V této sekci nalezneme archiv všech tiskových požadavků. Každý požadavek na tisk je uložen, je mu přiřazeno identifikační číslo a tiskárna, na které má být tisk proveden. Zde je možné sledovat stav dané tiskové úlohy - zda již byla přijata požadovanou tiskárnou, potažmo GPSServerem a zda proběhl tisk v pořádku. Význam jednotlivých sloupců je: Vytvořeno - čas vytvoření úlohy; Odesláno - čas odeslání tiskárně; Potvrzeno - čas potvrzení přijetí tiskárnou; Tiskárna - tiskárna, na které byl tisk proveden; Odpověď - odpověď tiskárny na úlohu.

90 B.2.6.5

PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA Soubory

V sekci soubory nalezneme správu všech souborů uložených v databázi. Jedná se o datové úložiště Resource souborů pro tisk - tzn. obrázků a log. Při tisku si GPSServery potřebné soubory stahují ze systému. Soubory jsou jednoznačně identifikovány názvem. Každý soubor je volitelného typu, tzv. MIME typu (např. image\png, image\jpg). Soubor je možné přidat stisknutím tlačítka Pridat soubor, v otevřeném dialogu vyplníte název (identifikace souboru, tímto názvem bude soubor odkazován), zvolíte MIME (viz. výše) a tlačítkem Procházet vyberete soubor na disku, který chcete nahrát do systému. Odesláním je vybraný soubor uložen.

Obrázek B.7: Dialog Přidání nového souboru Soubor můžete editovat (Edituj soubor ), smazat (Smaž soubor ) nebo stáhnout jeho zdrojová data uložená v systému (Stáhni soubor ).

B.3

Správa systému

Sekce správa systému slouží k nastavování parametrů slev, blokací, akcí, uživatelů a dalším operacím. V této sekci se nasazují nové akce a definuje předplatné. Sekce je rozdělena do samostatných částí.

B.3.1

Správa hledišť

Sekce správa hlediště slouží k definování hledišť v systému. Systém rozlišuje dva druhy hledišť: hlediště adresní, kde jsou sedadla číslována (mají sektor, řadu sedadlo) a hlediště neadresní, kde je pouze uvedena kapacita hlediště. Pro práci toto rozdělení příliš velký vliv nemá, i u neadresního hlediště vybíráte sedadla v plánku, ten je však zjednodušen a neuvádí umístění. Každé hlediště je pojmenováno, tzn. má vlastní název a kód (kód je přidělen dodavatelem systému a není doporučeno jej měnit). Dalšími parametry je kapacita adresního hlediště (Max adresní) a kapacita neadresního hlediště (Max neadresní). Do volitelného pole Poznámka můžete vložit interní poznámku. Parametr SVG src obsahuje interní odkaz na zdrojových kód hlediště a též jej jako kód hlediště není doporučeno měnit. Pokud chcete přidávat hlediště neadresní, jako SVG Src uveďte „n1.svgÿ, Max adresní zadejte „0ÿ a další parametry zadejte podle uvážení. Hlediště je možné přidávat (Nové hlediště ), editovat (Edituj hlediště ) nebo smazat (Smaž hlediště ). Vzhledem ke důležitosti nastavení správných hodnot doporučujeme práci s hledišti uživatelům se servisním oprávněním.

B.3. SPRÁVA SYSTÉMU

91

Obrázek B.8: Dialog Editace hlediště

B.3.2

Správa blokací

Přístup na sedadla je omezen blokacemi v systému. Blokace je v systému chápána jako vymezení skupiny uživatelů, kteří mají k sedadlu přístup, ostatní uživatele k sedadlu přístup nemají. Ke každému sedadlu může být přiřazena pouze jedna blokace. V systému jsou definovány dva speciální případy blokací: vyřazené sedadlo a výchozí blokace. Vyřazené sedadlo, jak je z názvu patrné, je označení sedadla, které je nepoužitelné. Speciální vlastností této blokace je, že při výpočtu statistik je na sedadla pohlíženo, že opravdu neexistují, u ostatních blokací jsou započítávána. Výchozí blokace je speciální typ blokace, kterou obsahují sedadla „bez blokaceÿ. Pokud nechcete sedadla blokovat, zvolte tuto blokaci. Všichni noví uživatelé systému jsou automaticky přiřazení do výchozí blokace.

Obrázek B.9: Dialog Přiřazení uživatelů blokace Blokacím je pro přehlednost možné přiřadit barvu (je zobrazována při nastavování blokace) a přiřadit uživatele, kteří mají k blokaci přístup. Přiřazení uživatelů k blokaci se provádí v dialogu přiřazení uživatelů a je vyvolán tlačítkem Přiřazení uživatelů na zvolené blokaci.

92

B.3.3


Správa slev

Výsledná cena vstupenky je dána výchozí cenou s možností ponížení pomocí systému slev. Slevy jsou v systému striktně pojmenované, při prodeji není možné slevu ručně nastavit, pouze vybrat ze seznamu slev. Výpočet slevy je zajištěn kombinací procentuální slevy a fixního zlevnění. Technicky řečeno je výpočet prováděn pomocí lineární rovnice o jedné neznámé: cenaf inal = k ∗ cena + q, kde k je koeficient (procenta děleno 100) a q je konstanta. Pro jednodušší pochopení je zde uvedena tabulka s příklady: Tabulka B.1: Příklady nastavení slev Sleva k q Sleva 50% 50 0 Fixní cena 100 Kč 0 100 Sleva 10% + 10 Kč příplatek 90 10 Zdarma 0 0 V systému můžete definovat libovolné množství pojmenovaných slev. Slevy je možné přidávat (Nová sleva), editovat (Edituj slevu) nebo smazat (Smaž slevu).

B.3.4

Správa her

Hra v systému je definována jako titul, název konané akce. Před založením jakékoliv akce je nutné nejdříve nadefinovat hry, které se budou konat. Hra může být buď repertoárová, tzn. opakující se, nebo nerepertoárová, tzn. konaná pouze jednou. Repertoárové hry jsou v seznamu her označeny modře. Každá hra může obsahovat „dataÿ. Data mohou být libovolné informace, které je potřeba u hry definovat. Může to být např. režisér, délka hry, atd. Tyto data jsou především využívána při tisku vstupenek jako dodatečné informace. Každá hra může mít také přiřazeny „typyÿ. Typ hry je vlastně její zatřídění, podle kterého je následně možné třídit nebo filtrovat. Příklad typu je balet nebo muzikál, typů může hra obsahovat více než jeden.

Obrázek B.10: Dialog Přiřazení typu hry Hry je možné vytvářet (Nová hra), editovat (Edituj hru) nebo mazat (Smaž hru). Editační okno je rozděleno na 3 karty: základní údaje, přiřazení typů a přiřazení dat.


B.3.5

93

Správa akcí

Jedna z nejobsáhlejších částí systému je správa akcí. Zde se nastavují parametry jednotlivých akcí a nasazují se akce nové. Pro pochopení terminologie je ještě nutné seznámit s vazbami Akce - Představení. Pod akcí si představme jednu akci, která se má konat a je jí přiřazeno hlediště. Akce pro plnou identifikaci ale nestačí, potřebujeme informaci, co a kdy se bude v dané akci konat a od toho máme Představení. Tudíž v rámci jedné akce se mohou představení měnit, což je v podstatě logický požadavek vycházející z praxe (představení se např. z důvodu nemoci ruší nebo přesouvají - např. přesunutí se takto velice jednoduše udělá tak, že se změní představení, ale akce vlastně zůstává stále stejná, včetně prodaných vstupenek) Každá akce může obsahovat „dataÿ a „typyÿ. Jedná se o analogické údaje jako u her, vysvětlení naleznete v kapitole Správa her. U každé akce je možné nastavit seznam povolených slev. Implicitně při vytváření akce je seznam povolených slev prázdný, povolené slevy je možné označit v kartě Slevy v editaci/vytvoření akce. U akce je dále evidován stav pro export, což je informace, jak má být akce exportována na internet do systému WebTicket3 a zda je akce aktivní a určena k prodeji. U každé akce je možné nastavit parametry pro jednotlivé cenové kategorie. Cenová kategorie je nastavení dodatečné slevy u prodaných vstupenek. Tato sleva se počítá až po započtení základní slevy. Zákazníkům systému je možné přiřadit některou z nadefinovaných cenových kategorií a tím jim poskytnout ještě dodatečnou slevu. Příkladem cenové kategorie je např. stálý zákazník, kterému chcete poskytnout oproti běžným zákazníkům cenové zvýhodnění. B.3.5.1

Nová akce

Základním způsobem založení akce je přes tlačítko Nová akce. Zobrazený dialog je poté nutné vyplnit takto: • Záložka akce Zvolíme hlediště a pokud je hlediště neadresní, MUSÍME zadat počet neadresních míst (u adresního hlediště nevyplňujeme). Dále můžeme vyplnit volitelnou poznámku změnit stav pro export. • Záložka představení Zde zvolíme konanou hru (titul), datum a čas. • Záložka cen. kat. Zde se nastavují parametry cenových kategorií, sleva procentuální k a fixní q. • Záložka slevy Zde je možné zvolit seznam povolených slev • Záložka přiřazení typů Zde zvolíme v seznamu označit typy akce • Záložka nastavení dat Zde nastavíme doplňující data akce 3

Systém WebTicket je nadstavba systému GEMINI, zajišťující rezervaci a prodej vstupenek přes internet

94


Po uložení dialogu se v systému vytvoří nová akce, která ale nemá nastaveny ceny sedadel a blokace. Pro dokončení je nutné pokračovat přes operaci Detail akce (viz. dále).

B.3.5.2

Detail akce

V detailu akce nastavujeme cenu sedadel, barvu sedadla a blokaci. V levé části dialogu máme vykreslené hlediště a v pravé kartu se třemi záložkami. Sedadla jsou jednoduše označována kliknutím a případným tažením přes další sedadla. Pokud chceme zjistit aktuální nastavení ceny/barvy/blokace u daného sedadla, stihneme současně l-ctrl a levé tlačítko myši nad požadovaným sedadlem. Hodnota ze sedadla bude překopírována do nastavovacího políčka. INFO: Veškeré změny, které jsou v prohlížeči prováděny nebudou v systému zaznamenány, dokud nebudou změny uloženy tlačítkem Uložit!

Obrázek B.11: Dialog Nastavení ceny U nastavování ceny / barvy zadáme do nastavovacího políčka požadovanou cenu / barvu nebo ji načteme ze sedadla a poté již jednoduchým označováním nastavíme požadovanou hodnotu na zvolená sedadla. U nastavování ceny je navíc k dispozici tlačítko Nastav na všechna sedátka, které nastaví zvolenou cenu pro celé hlediště. Podbarvení hlediště je vypočítáváno podle nastavených cen - od nejlevnějších (nejsvětlejší) po nejdražší (nejtmavší). U nastavování blokace vybereme ze seznamu požadovanou blokaci (nebo ji načteme ze sedatka dle pokynů výše) a opět sedadla jednoduchým způsobem označujeme.


95

Obrázek B.12: Dialog Nastavení blokace B.3.5.3

Detail akce

Detail akce slouží ke změně parametrů již založené akce. Není možné měnit vybrané hlediště, ostatní parametry je možné libovolně měnit.

B.3.5.4

Kopírování akce

Kopírování akce je nástroj pro rychlé nasazování akcí. Filozofie nástroje vychází z praxe, kdy většina nasazovaných akcí mají stejné parametry cen a pouze se liší v konané hře (titulu). Díky tomuto nástroji je možné vzít vybranou akci jako vzor a zkopírovat nastavení cen, barev, blokací a parametrů do nové akce, aniž bychom museli pracně všechna data opětovně vyplňovat.

Obrázek B.13: Dialog Kopírování akce

96


Vybereme tady akci, kterou budeme považovat jako vzor a klikneme na tlačítko Kopírovat. Ze vzoru je možné vytvořit najednou více kopií, každou další kopii přidáme stisknutím tlačítka Přidej řádek, v případě potřeby je řádky možné odstraňovat (Odstraň řádek ). Minimem je nutnost vyplnit datum a čas nové akce. U nově vznikající akce je již nyní možné zvolit jinou hru, pokud necháme políčko prázdné, použije se stejná hra, jakou má vzorové akce. Následují zaškrtávací políčka vč. dat, které zajistí zkopírování nastavených dat (implicitně není prováděno), vč. typů, které zajistí nastavení stejných typů (implicitně není prováděno) a políčko pro nastavení stav pro export u nové akce. Postupným přidáváním řádků a nastavováním parametrů si vytvoříme seznam ke kopírování a jakmile jsme připraveni, seznam odešleme a systém vytvoří požadovaný počet kopií dle nastavených parametrů.

B.3.6

Správa předplatného - definice typů

V této sekci se nastavují parametry předplatitelských skupin. Systém rozlišuje dva druhy předplatného: fixní a volné. Fixní předplatné je vázáno na konkrétní sedadlo v hledišti, na kterém po celou dobu platnosti předplatného zákazník sedí. Naopak volné předplatné dává zákazníkovi volnost ve výběru sedadla a akce, kterou chce navštívit. Každé předplatné má určeno, na kolik akcí má zákazník předplaceno. Každý typ předplatného je chápán jako předplatitelská skupina, kde každá skupina může mít libovolný počet návštěv (počet předplacených představení) a libovolný počet cenových zón (slev). Například máme předplatitelskou skupinu „Aÿ, která obsahuje 6 návštěv a může být prodávána za plnou cenu a se slevou pro děti a studenty (3 cenové zóny: plná cena, děti, studenti).

Obrázek B.14: Dialog Nový typ předplatného Nejdříve je nutné vytvořit předplatitelské skupiny - typy legitimací. Tlačítkem Nový typ založíme nový typ předplatného. Vybereme, zda se jedná o volné nebo vázané předplatné, zvolíme název, počet návštěv a zadáme omezení platnosti legitimace. Pro vázané předplatné musíme zvolit hlediště ve kterém se akce budou konat (vázané předplatné je na konkrétní sedadlo a tudíž není možné, aby se představení mohly konat v různých hledištích). Tlačítkem Uložit nový typ založíme. Založené typy je možné editovat (Edituj typ), nicméně je možné pouze měnit název a dobu platnosti, ostatní údaje již měnit možné není. Pro každý typ předplatného je potřebné nastavit parametry jednotlivých návštěv (Návštěvy). Pro každou návštěvu je možné určit buď zvolenou akci (u vázaného předplatného je tato položka povinná) nebo pouze typ akce pro volbu akcí, které je možné v


97

rámci dané návštěvy shlédnout. Pokud zaškrtnete políčko Inverze, je možné shlédnout všechny akce mimo vybrané, tudíž se jedná o inverzní výběr akce.

Obrázek B.15: Dialog Editace návštěv Pro každý typ předplatného je potřebné nastavit minimálně jednu cenovou zónu. Cenová zóna určuje, jak bude vypočtena výsledná cena legitimace. Cenové zóny nastavujeme přes příkaz Cenové zóny. Každá cenová zóna je pojmenovaná, v dialogu Cenových zón je možné jednotlivé zóny zakládat (Nová zóna), smazat (Smaž zónu) a nastavovat (Edituj zónu). Zóny tedy nejprve založíme a poté pomocí editace nastavíme parametry. Pro nastavení parametrů je zobrazen dialog Editace cenové zóny. Zde pro každou návštěvu určujeme parametry výpočtu ceny výsledné. U každé návštěvy můžeme jako výchozí cenu (nominální hodnota) pro výpočet zvolit buď výchozí cenu sedadla (dle sedadla) nebo ji přímo zadáme do kolonky Nom. hodn. (nominální hodnota). Cena výsledná je opět vypočtena dle parametrů k a q stejným algoritmem jako u slev, kde výchozí cenou je nominální hodnota. Výsledná cena legitimace je poté vypočtena jako součet všech dílčích výsledných cen za všechny návštěvy.

Obrázek B.16: Dialog Editace cenové zóny Typ předplatného je možné smazat tlačítkem Smaž typ.

98


B.3.7

Správa pracovišť

Správa pracovišť slouží k přidávání, editaci a mazání pracovišť. Pracoviště je označení místa, odkud se uživatelé přihlašují. Pro každé pracoviště jsou ukládány nastavení v průběhu práce uživatele (např. tiskárny) na daném pracovišti. V případě změny pracoviště (např. přesun z obchodního oddělení do pokladny) se uživatel přihlásí do nového pracoviště a všechna nastavení jsou automaticky změněna pro práci ve změněném pracovišti.

B.3.8

Správa uživatelů

Zde je zajištěna správa všech uživatelů, kteří mají do systému přístup. Každý uživatel se přihlašuje uživatelským jménem a heslem. V systému jsou definovány uživatelské role pro omezení přístupu k jednotlivým částem systému. Uživateli je takto přiřazena jedna role. Uživatel má též nastaveno výchozí pracoviště, které je nastaveno při přihlášení, pokud uživatel při přihlašování pracoviště nevybere. V případě ztráty hesla může uživatel s patřičným oprávněním (např. Administrátor) změnit heslo bez znalosti hesla původního (tlačítko Změnit heslo). Pro dočasné zablokování účtu je možné využít položky aktivní v editaci uživatele, neaktivní uživatel se do systému nepřihlásí.

Obrázek B.17: Dialog Editace uživatele Položka Perzistentní SID je využívána pro interní potřebu pro virtuální uživatele systému. Běžní uživatele nesmí mít tuto položku zaškrtnutou.

B.3.9

Změna hesla

Pomocí této funkce si může aktuálně přihlášený uživatel změnit svoje heslo pro přihlášení do systému. Jako potvrzení je vyžadováno nejdříve heslo původní a poté nové.

B.3.10

Číselníky

Číselníky jsou v systému využívány pro nastavení cenových kategorií, dat her a akcí a typu her a akcí. • Cenové kategorie - Zde nastavujeme názvy jednotlivých cenových kategorií. Cenové kategorie je možné následně přiřazovat zákazníkům a v editaci akcí je možné nastavovat procentuální a fixní slevy daných cenových kategorií.

B.4. STATISTIKY

99

• Typy akcí, typy her - Zde nastavujeme názvy typů akcí a her, které je možné přiřazovat akcím a hrám. • Data akcí, data her - Zde nastavujeme názvy dat akcí a her, které je možné nastavovat v akcích a hrách. Číselník dat je ukládán jako klíč-název, kde klíč je s nastavenou hodnotou vkládán do šablony při tisku vstupenky a název je zobrazován při nastavování hodnoty ve správě akcí a her.

B.4

Statistiky

Sekce statistik slouží k souhrnným a statistickým výstupům ze systému. Obsaženy jsou základní statistiky zobrazující denní a volitelné uzávěrky, statistiku prodejnosti, přehled dokladů. Kromě statistiky akcí pracuje tvorba statistiky na stejném principu. Při prvním otevření okna statistiky jste vyzváni k zadání potřebných parametrů a po stisknutí tlačítka Vytvořit je statistika vygenerována. Důležitým parametrem je Volba výstupu. Tím určujeme, kam má být statistika vygenerována, zda do okna aplikace nebo do samostatného okna. Pokud chcete statistiku tisknout, je potřebné vygenerovat statistiku v HTML do nového okna a poté jí již standardní cestou vytisknout (v prohlížeči si již můžete nastavit velikost, otáčení, atd.).

Obrázek B.18: Volba výstupu Speciálním typem je Statistika akcí, která slouží jako rozcestník pro další statistiky. Z této statistiky je možné tisknout Souhrn a Statistiku 1 (statistika jedné vybrané akce). První statistika slouží k otevření podrobnější verze statistiky akcí (je aplikován stejný filtr jako v zobrazené statistice akcí) a druhá pro detailní statistiku jedné vybrané akce.

Obrázek B.19: Statistika akcí

100

B.5


Prodej

Sekce prodej zajišťuje veškerý prodej vstupenek a legitimací, včetně jejich stornování.

B.5.1

Adresář

Sekce Adresáře obsahuje správu všech zákazníků vedených v systému. V hlavním okně vidíme seznam obsahující jméno, organizaci a adresu. Ve filtrech v pravé části je speciální položka Rychlé hledání, která vyhledává v zobrazeném textu fulltextově, ostatní položky filtru již vyhledávají v daných atributech.

Obrázek B.20: Adresář Zákazníky je možné vytvářet (Nový kontakt), editovat (Edituj kontakt) nebo mazat (Smaž kontakt). Speciální funkcí je Sloučení kontaktu. Běžným nešvarem obsáhlých databází je duplicita dat, zde např. zákazníků. Funkce sloučení kontaktů je navržena tak, aby bylo možné dva nalezené duplicitní zákazníky sloučit v jednoho a tím duplicitu odstranit. Nejprve vybereme 1. záznam v seznamu a klikneme na Sloučení kontaktů, zobrazí se dialog, ve kterém vybereme 2. záznam a odesláním systém zajistí sloučení zákazníků.

Obrázek B.21: Dialog Výběr zákazníka

B.5. PRODEJ

101

Pokud chceme vybrat zákazníka (např. přiřadit zákazníka k zakázce), otevře se dialog výběru zákazníka. V otevřeném dialogu je zobrazen seznam zákazníků, ve kterém je možné rychle vyhledávat zadáváním hledaného textu do pole Hledaný výraz. Zákazníky je i v tomto dialogu možné přidávat (Nový kontakt) nebo editovat (Edituj kontakt, příp. dvojklikem). Zákazníka vybereme označením požadovaného kontaktu a stisknutím tlačítka Vyber kontakt dialog odešleme. Tlačítkem Storno výběr zrušíme.

B.5.2

Košík

Nákupní košík je analogií nákupního košíku např. v supermarketu nebo elektronickém obchodě. Do nákupního košíku jsou vkládány vstupenky a legitimace, které posléze na pokladně zaplatíme. Každý přihlášený uživatel má svůj košík. Košík je zachován i po odhlášení uživatele, proto je důrazně doporučeno před odhlášením košík buď prodat nebo vyčistit. Okno košíku je zobrazeno v sekci Prodej. Ve většině části košíku (vlevo) nalezneme obsah košíku, vstupenky jsou seskupeny po jednotlivých akcích, legitimace jsou zobrazeny samostatně. Jednotlivé položky košíku je možné editovat nebo odstranit (pravým tlačítkem na vybrané položce vyvoláme kontextové menu s možnými operacemi s položkou). Pokud dáme editovat vstupenky na vybranou akci, otevře se dialog s hledištěm, kde je možné přidávat, ubírat nebo měnit jednotlivé vstupenky (podrobnější informace v sekci Seznam akcí).

Obrázek B.22: Nákupní košík V pravé části košíku se nachází ovládací panel, kde je možné provádět operace s košíkem. Košíku můžeme přiřadit zákazníka, kterému je poté košík možné prodat (možné je samozřejmě prodat vstupenky anonymnímu zákazníkovi - tím, že zákazníka nevybereme). Pod zákazníkem nalezneme aktuální hodnotu všech položek uložených v košíku. S košíkem je možné provádět tyto operace:

Obrázek B.23: Dialog Nové rezervace

102


Rezervovat Sedadla v košíku můžete zarezervovat na jméno (vyplněný zákazník se zde nepoužije - může být anonymní). Rezervovat lze pouze sedadla, legitimace v košíku zůstávají! Pokud máte v košíku vstupenky na více akcí najednou, vytvoří se tolik rezervací, kolik různých akcí (a sedadel na ně) je v košíku. Kliknutím na tlačítko Rezervovat je vyvolán dialog vytvoření rezervace. Zde je nutné vyplnit Jméno, pod kterým bude rezervace vedena (může to být libovolný text identifikující rezervaci a musí obsahovat minumálně 3 znaky). Dále je předvyplněna expirace, kterou je možné změnit. Po vypršení rezervace, jejíž platnost právě udává Expirace je rezervace automaticky zrušena a sedadla uvolněny do prodeje. Po kliknutí na tlačítko Uložit jsou rezervace vytvořeny a sedadla z košíku odstraněna. Prodat Sedadla a legitimace v košíku můžete rychle prodat hotově nebo platební kartou. Z košíku je vytvořena zjednodušená zakázka a po provedeném prodeji je vytvořen potřebný účetní doklad (prodejka nebo faktura).

Obrázek B.24: Dialog Rychlého prodeje Kliknutím na tlačítko Prodat je vyvolán dialog prodeje / vytvoření zjednodušené zakázky. V dialogu nalezneme výslednou cenu, která bude zaúčtována. V seznamu pod cenou nalezneme seznam možností tisku po provedeném prodeji. Pokud chceme rovnou vytisknout vstupenky, zaškrtneme položku „vstupenkyÿ, pokud chceme rovnou vytisknout učetní doklad (prodejku, fakturu), zaškrtneme „dokumentyÿ. Prodej dokončíme stisknutím tlačítka s typem platby (Hotovost nebo Karta). Po provedeném prodeji je košík vyčištěn a podle nastavení vytištěny vstupenky a účetní doklad. Vytvořit zakázku Sedadla a legitimace je možné vložit do zakázky pro pozdější úpravy, příp. pro prodej zakázky zaplacené bankovním převodem. Před vytvořením zakázky je nutné v košíku přiřadit zákazníka - zakázku není možné vytvořit anonymnímu zákazníkovi. Kliknutím na tlačítko Zakázka je vyvolán dialog Vytvoření zakázky. Zde jsou pro informaci zobrazeny fakturační údaje a je možné zákazníka změnit, příp. mu upravit fakturační údaje (kliknutím na zákazníka je vyvolán dialog Výběru zákazníka, kde je možné zákazníka editovat - obrázek B.21). Dále jsou zobrazeny položky zakázky, celková cena a tlačítka pro práci se zakázkou. Tlačítkem Vytvořit doklad/prodat zakázku prodáme a vytvoříme účetní doklad,

B.5. PRODEJ

103

Obrázek B.25: Dialog Vytvoření zakázky bližší informace jsou uvedeny v následující kapitole Zakázky. Tlačítkem Uložit zakázku uložíme, ale neprodáme. Taková zakázka je tzv. „otevřenáÿ a je možné ji např. vymazat, zatím není vytvořen žádný účetní doklad, sedadla a legitimace jsou v zakázce pouze zablokované pro zákazníka. Tlačítkem Zavřít okno tvorbu zakázky zrušíme a vrátíme se do košíku. Vymazat Obsah košíku je možné najednou vymazat tlačítkem Další-Vyčisti košík.

B.5.3

Zakázky

V této sekci je možné pracovat s jednotlivými zakázkami. V seznamu nalezneme vedle zákazníků stav zakázky, její celkovou cenu a stav zaplacení. Zakázky, které jsou otevřené mají zelenou barvu, zakázky stornované šedivou. Zakázky je možné editovat (Editace zakázky) nebo stornovat (Storno zakázky). Stornování zakázky vede ke kompletnímu stornování celé zakázky. V dialogu zvolíme typ platby, po odeslání je zakázka vystornována a je vytvořen adekvátní storno účetní doklad. Pokud chceme tento doklad rovnou vytisknout, zaškrtneme ve volbách tisku dokumenty.

Obrázek B.26: Dialog storno zakázky

104


V editaci zakázky můžeme u otevřené zakázky zakázku prodat - vytvořit doklad, příp. změnit zákazníka nebo odebrat zvolená sedadla, u prodané (uzavřené) zakázky můžeme pro vybrané sedadlo vytisknout duplikát vstupenky.

Obrázek B.27: Dialog Editace zakázky Pokud chceme změnit zákazníka, klikneme na něj a v zobrazeném dialogu Výběru zákazníka zvolíme jiného. Pokud chceme zakázku prodat (je otevřená), zvolíme tlačítko Vytvořit doklad/prodat a zvolíme Faktura. V následujícím dialogu zvolíme typ platby a pomocí zaškrtávacích políček vybereme, zda chceme tisknout vstupenky a účetní doklad. Vzhled dialogu je analogický dialogu B.26 a proto zde není uveden.

Obrázek B.28: Dialog Tisk jednotlivých vstupenek Kliknutím pravým tlačítkem na položkách zakázky je vyvoláno kontextové menu dané položky, u prodaných sedadel je možné vybírat z detailu položky (seznam prodaných sedadel) a tisku vstupenek. V obou případech je vyvolán dialog se seznamem prodaných sedadel pro vybranou akci (položku zakázky). U tisku vstupenek je u každého sedadla zaškrtávací políčko, pomocí kterého je možné vybrat sedadla, pro které chceme vstupenky tisknout a kliknutím na Tiskni vybrané jsou vstupenky vytištěny.

B.5. PRODEJ

B.5.4

105

Seznam akcí

V seznamu akcí vybíráme sedadla pro prodej a získáváme informace o jednotlivých akcích. V seznamu máme aktuální přehled volných a rezervovaných míst pro každou akci.

Obrázek B.29: Seznam akcí Pokud chceme zobrazit detailní informaci o akci, požadovanou akci vybereme a zvolíme Detail akce. Ve vyvolaném dialogu je zobrazen plánek hlediště s obarvenými sedadly podle jejich stavu: Tmavě modrá: Sedadlo prodané Světle modrá: Sedadlo v košíku/zakázce (nezaplacené) Zelená: Rezervované sedadlo Fialová: Obsazené sedadlo předplatitelem Černá: Vyřazené sedadlo Ostatní: Volné sedadlo Podrobnější informace získáme kliknutím na vybrané sedadlo, v pravé části dialogu nám jsou zobrazeny detaily o sedadle (v jaké je zakázce, kdo a kdy sedadlo prodal, atd.) Pokud chceme sedadla prodat nebo rezervovat (v této fázi nezáleží, co se sedadly budeme dělat, jelikož vybraná sedadla nejdříve vkládáme do košíku a poté následně vybíráme, co s košíkem budeme dělat), v seznamu akcí vybereme požadovanou akci a klikneme na Nový prodej/rezervace. V následujícím dialogu v hledišti vybereme požadovaná sedadla a výběr odešleme (tím jsou sedadla uložena do košíku). Během výběru je možné vybírat sedadla najednou s různými slevami. V roletovém menu vpravo vybereme požadovanou slevu a označujeme sedadla. Označená sedadla mají červenou barvu. Dále můžeme v roletovém menu vybrat další slevu a označujeme další sedadla. Označená sedadla s jinou slevou, než máme aktuálně vybranou maji oranžovou barvu. Zobrazovaný součet ukazuje počet vybraných sedadel a cenu po započtení slev. Ostatní barvy sedadel identifikují jejich stav, jak bylo popsáno výše u detailu akce.

106


Obrázek B.30: Dialog Nový prodej/rezervace

B.5.5

Rezervace

Zde je možné spravovat všechny rezervace vedené v systému. V seznamu nalezneme veškeré důležité informace jako jméno, akci, počet vstupenek, celková cena, datum a čas expirace. Pokud chceme rezervaci prodat, můžeme to udělat dvěma způsoby: vložit přímo rezervaci do košíku nebo ji nejprve změnit a poté vložit do košíku. Jak již bylo naznačeno, pokud chceme rezervaci prodat, vždy to děláme přes košík, který následně prodáme. Pokud chceme rezervaci zrušit, vybereme požadovanou rezervaci a klikneme na Zruš rezervaci. Pro přímé vložení rezervace bez úprav do košíku použijeme tlačítko Ulož rezervaci do košíku a pro změnu rezervace a případný následný prodej použijeme tlačítko Edituj rezervaci. Druhá varianta je především vhodná, pokud před vložením do košíku chceme rezervaci zkontrolovat nebo např. dodatečně uplatnit slevu na rezervované vstupenky. V dialogu Editace rezervace můžeme uloženou rezervaci změnit (přidat nebo ubrat sedadla, změnit slevy) a znovu uložit. Pokud chceme změněnou rezervaci uložit, klikneme na Uložit, pokud chceme rezervaci vložit do košíku, zvolíme tlačítko Do košíku. Máme na výběr 2 varianty uložení rezervace do košíku, pokud rezervaci změníme (především snížíme počet sedadel), můžeme upravenou rezervaci vložit do košíku a původní místa uvolnit nebo ponechat. Tuto volbu děláme po stisknutí tlačítka Do košíku. Jestliže chceme např. prodat část rezervace a zbylá místa v rezervaci ponechat, zvolíme . . . a ponechat zbytek rezervace, v opačném případě zvolíme . . . a zruš rezervaci.

B.5. PRODEJ

107

Obrázek B.31: Dialog Editace rezervace

B.5.6

Předplatné

V této sekci spravujeme předplatitelské legitimace. Předplatitelské legitimace můžeme vytvářet (Nová legitimace), získat detailní informace o legitimaci (Detail legitimace), vytisknout (Tisk legitimace) nebo změnit sedadlo ve fixním předplatném (Změň sedadlo). Změna sedadla slouží pro přesazení předplatitele na nové sedadlo v rámci typu předplatného. Přesazení nemá vliv na cenu legitimace. Při výběru změny sedadla je vyvolán dialog pro zvolení nového sedadla. Sedadlo aktuální je světle červené. Při výběru sedadla systém informuje, zda je nově vybrané sedadlo levnější (zelená), dražší (žlutá) nebo za stejnou cenu (bílá). Při vytváření legitimace postupujeme ve dvou krocích. Nejprve zvolíme typ předplatného a poté v následujícím dialogu zvolíme sedadla.

Obrázek B.32: Dialog Výběr typu legitimace Zobrazená cena u každého sedadla informuje o ceně legitimace vybrané cenové zóny pro toto sedadlo. Výběr zón a označování sedadel funguje analogicky výběru sedadel při prodeji vstupenek. Je možné zvolit více sedadel, podle počtu vybraných sedadel je vytvořen počet legitimací. Zvolené legitimace jsou odesláním uloženy do košíku.

108


Obrázek B.33: Dialog Výběr sedadla pro legitimaci

B.5.7

Doklady

Sekce Doklady obsahuje všechny doklady vystavené systémem. Systém automaticky vystavuje tyto druhy dokladů: • Proforma faktury • Prodejky • Faktury • Dobropisy • Interní doklady • Příjmové pokladní doklady • Výdajové pokladní doklady Doklady je možné vyhledávat nebo opakovaně tisknout.

B.5.8

Seznam vstupenek

Seznam vstupenek slouží k dohledání a opakovanému tisku vstupenek. Kliknutím na Detail vstupenky získáme dialog s podrobnými informacemi o vstupence, tzn. kdo a kdy vstupenku prodal, na jaké místo a akci. V případě požadavku je možné vytisknout duplikát vstupenky, tím původní vstupenka pozbývá platnosti, protože je nahrazena duplikátem z novým číslem vstupenky.

B.6. GPS (APLIKACE)

B.5.9

109

Storna vstupenek

Sekce Storna vstupenek slouží ke stornování jednotlivých vstupenek pomocí zadávání čísel vstupenek. Číslo vstupenky zadáme do políčka Vstupenka a stiskneme ENTER. Vstupenka je následně vyhledána v systému a přidána do seznamu vstupenek ke stornování. V seznamu jsou vstupenky seskupovány po zakázkách a je zobrazován typ platby, jakým byly vstupenky uhrazeny. Pokud jsou přidány vstupenky uhrazené jinak než hotově (cash) a kartou (card), je zobrazeno varovné okno, že stornujete vstupenky uhrazené jinak než hotově4 . Vstupenka touto operací stornována ještě není!

Obrázek B.34: Storna vstupenek Po vytvoření seznamu ke stornování zvolíme Stornuj vstupenky, v otevřeném dialogu vybereme způsob úhrady a odesláním dojde k fyzickému stornování vstupenek. Při stornování vstupenek systém vytvoří automaticky potřebné storno doklady (např. výdajový pokladní doklad).

B.6

GPS (aplikace)

GPS (Gemini Print Server) je malá JAVA aplikace zajišťující tisk ze systému, která běží na pozadí a sleduje, zda v systému nepřibyla nová tisková úloha pro připojené tiskárny. Pokud chceme tisknout, musíme na počítačích, ke kterým jsou tiskárny připojené, mít nakonfigurovaný a spuštěný GPS program. GPS může obsluhovat více tiskáren najednou, stačí do konfiguračního souboru doplnit tolik tiskáren, kolik jich budeme používat. Spuštěné GPS umístí do tray ikonu s modrým obdélníkem s nápisem GPS, kliknutím pravým tlačítkem získáme kontextové menu, ze kterého můžeme buď GPS ukončit nebo zobrazit stav. Ve stavovém okně nalezneme zda je GPS registrováno (ověřeno v systému GEMINI) a počet úspěšných a neúspěšných požadavků. Pro každou tiskárnu je též vedena evidence provedených tisků.

B.6.1

Konfigurační soubor

Konfigurační soubor obsahuje nastavení GPS. Základní parametry jsou komentovány, tudíž další vysvětlování zde není nutné. Tiskárny, které jsou obsluhovány jsou uvedeny 4

U vstupenek hrazených jinak než hotově a kartou(především bankou) je předpokládána úhrada na fakturu a tím pádem by měla být stornována přes dobropis

110


Obrázek B.35: GPS - stavové okno v <entry key="prn">, stejně pojmenované musí být v nastavení GPS/Tiskárny v sekci Servis. Pro tisk jsou používány dva ovladače: JavaFO a JavaGPS. JavaFO používá technologii XSL-FO a je především využíván k tisku dokladů (volte u tiskáren na doklady). JavaGPS používá interní jazyk GPS a je využíván k tisku vstupenek a legitimací (volte u tiskáren na vstupenky a legitimace). V dalším řádku nalezneme parametr param1, tento parametr musí obsahovat přesný název tiskárny ve Vašem systému (např. PDFCreator, HP LaserJet 6P, atd. . .). Vzor konfiguračního souboru: <properties> <entry key="gps.gui">true <entry key="gps.port">1111
parametry pro pripojeni ke vstupenkovemu systemu --> key="gemini.url">https://localhost:8443/gps2 key="gemini.auth_name">username key="gemini.auth_pass">password

<entry key="prn">doklady_1,vstupenky_1 <entry key="prn.doklady_1.driver">JavaFO <entry key="prn.doklady_1.param1">PDFCreator <entry key="prn.vstupenky_1.driver">JavaGPS <entry key="prn.vstupenky_1.param1">PDFCreator

Příloha C

Obsah přiloženého CD Na přiloženém CD je následující adresářová struktura: • /dist/gemini/ - distribuční soubory systému Gemini • /dist/gps/ - distribuční soubory Gemini Print Serveru • /help - dokumentace systému (uživatelská a instalační příručka) • /src/gemini/ - zdrojové kódy systému Gemini • /src/gps/ - zdrojové kódy Gemini Print Serveru • /text/src - zdrojové soubory dimplomové práce v LATEXu • /text - text diplomové práce • readme - soubor s popisem obsahu CD

111

Vstupenkový informační systém divadla

Recommend Documents