Vstupenkový informační systém divadla

Transkript

1 Č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

2 iv

3 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.

4 vi

5 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

6 viii

7 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

8 x

9 Obsah 1 Úvod 1 2 Použité technologie Java EE Java Servlets Java Servlet API Interakce klient-server Životní cyklus servletu Javascript AJAX SVG Skriptování a animace Podpora pro SVG ve webových prohlížečích XSLT a XSL-FO Jetty ExtJS PostgreSQL Úvodní studie Současný stav Celorepublikoví prodejci Samostatné systémy Proč vlastní řešení? Deklarace záměru Odborný článek Tisk vstupenek Jehličkové tiskárny Laserové a inkoustové tiskárny Termální nebo termotransferové tiskárny Nefunkční požadavky Návrh architektury Analýza rizik Rizika technologická Nedostatečné nástroje pro vývoj Nekompatibilita HW a SW Výkonnost HW a SW Rizika procesní Chyby v analýze Odklon od požadavků xi

10 xii OBSAH Špatný odhad velikosti Rizika implementační Nepochopení ovládání Znalosti použitých technologií Nedostatečné testování Rizika bezpečnostní Chyba SW Chyba HW Analýza řešení Seznam aktérů Analýza případů použití 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 Seznam zakázek Vyhledání zakázky Storno zakázky Editace zakázky Vystavení dokladu Konceptuální datový model

11 OBSAH xiii 5 Návrh a Implementace Fyzický datový model Databázové tabulky Uložené procedury Popis komponent Package cz.comnet.gemini Package cz.comnet.gemini.cronlib Package cz.comnet.gemini.guiext Package cz.comnet.gemini.modules GUI Gemini Print Server Testování Testování kódu white-box testování black-box testování Testování databáze Testování GUI Usability testy Závěr Zhodnocení Budoucnost Literatura 77 A Instalační příručka 79 A.1 Minimální systémové požadavky A.2 Instalace podpůrných aplikací A.3 Instalace serveru A.4 Instalace GPS Serveru B Uživatelská příručka 83 B.1 Úvod B.1.1 Základní informace o systému 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 Servery B Tiskárny B Šablony B Úlohy B Soubory

12 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 Nová akce B Detail akce B Detail akce B 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 111

13 Seznam tabulek 3.1 Porovnání jednotlivých druhů tisku Souhrn rizik vyvíjeného systému Use Case: Přihlášení uživatele Use Case: Autentizace uživatele Use Case: Odhlášení uživatele Use Case: Změna hesla přihlášeného uživatele Use Case: Správa uživatelů Use Case: Přidání uživatele Use Case: Editace uživatele Use Case: Změna hesla uživatele Use Case: Smazání uživatele Use Case: Seznam uživatelů Use Case: Vytvoření nového zákazníka Use Case: Vyhledání zákazníka Use Case: Smazání zákazníka Use Case: Editace zákazníka Use Case: Sloučení zákazníka Use Case: Seznam akcí Use Case: Výběr sedadel Use Case: Detail akce Use Case: Vyhledání akce Use Case: Vytvoření nové legitimace Use Case: Vytvoření fixního předplatného Use Case: Vytvoření volného předplatného Use Case: Nákupní košík Use Case: Prohlížení košíku Use Case: Smazání košíku Use Case: Rezervace košíku Use Case: Prodej košíku Use Case: Vytvoření zakázky Use Case: Výběr zákazníka Use Case: Správa zakázek Use Case: Vyhledání zakázky Use Case: Storno zakázky Use Case: Editace zakázky Use Case: Vystavení dokladu Databázová tabulka: abonma xv

14 xvi SEZNAM TABULEK 5.2 Databázová tabulka: abonmatypy Databázová tabulka: abonmatypyd Databázová tabulka: abonmazony Databázová tabulka: abonmazonyd Databázová tabulka: abonmad Databázová tabulka: akce Databázová tabulka: akcecenovekategorie Databázová tabulka: akcedata Databázová tabulka: akceslevy Databázová tabulka: akcetypy Databázová tabulka: akced Databázová tabulka: blokace Databázová tabulka: blokaceuzivatele Databázová tabulka: doklady Databázová tabulka: hlediste Databázová tabulka: hledistesedadla Databázová tabulka: hledistesektory Databázová tabulka: hry Databázová tabulka: hrydata Databázová tabulka: hrytypy Databázová tabulka: kontakty Databázová tabulka: platby Databázová tabulka: pracoviste Databázová tabulka: predstaveni Databázová tabulka: prodeje Databázová tabulka: rezervace Databázová tabulka: rezervaced Databázová tabulka: role Databázová tabulka: roleopravneni Databázová tabulka: sabonma Databázová tabulka: sabonmad Databázová tabulka: slevy Databázová tabulka: sprodeje Databázová tabulka: uzivatele Databázová tabulka: vstupenky Databázová tabulka: zakazky B.1 Příklady nastavení slev

15 Seznam obrázků 3.1 Architektura systému 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 xviii SEZNAM OBRÁZKŮ 5.1 ER Diagram B.1 Hlavní okno aplikace B.2 Seznam akcí B.3 Menu aplikace B.4 Dialog Editace oprávnění role B.5 Dialog Editace cron záznamu B.6 Dialog Editace tiskárny B.7 Dialog Přidání nového souboru B.8 Dialog Editace hlediště B.9 Dialog Přiřazení uživatelů blokace B.10 Dialog Přiřazení typu hry B.11 Dialog Nastavení ceny B.12 Dialog Nastavení blokace B.13 Dialog Kopírování akce B.14 Dialog Nový typ předplatného B.15 Dialog Editace návštěv B.16 Dialog Editace cenové zóny B.17 Dialog Editace uživatele B.18 Volba výstupu B.19 Statistika akcí B.20 Adresář B.21 Dialog Výběr zákazníka B.22 Nákupní košík B.23 Dialog Nové rezervace B.24 Dialog Rychlého prodeje B.25 Dialog Vytvoření zakázky B.26 Dialog storno zakázky B.27 Dialog Editace zakázky B.28 Dialog Tisk jednotlivých vstupenek B.29 Seznam akcí B.30 Dialog Nový prodej/rezervace B.31 Dialog Editace rezervace B.32 Dialog Výběr typu legitimace B.33 Dialog Výběr sedadla pro legitimaci B.34 Storna vstupenek B.35 GPS - stavové okno

17 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. B. Nedílnou součástí práce je instalační a uživatelská příručka, které tvoří přílohy A a 1

18 2 KAPITOLA 1. ÚVOD

19 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 JVM 1. Se servlety se setkáme též např. při technologii JSP 2. Servlety 1 Java Virtual Machine 2 Java Server Pages 3

20 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 CGI 3 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 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 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]

21 2.3. JAVASCRIPT Ž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é MIME 5, 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

22 6 KAPITOLA 2. POUŽITÉ TECHNOLOGIE 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 DOM 6. 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.

23 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 em 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 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 SMIL 7 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 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

24 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 Adobe 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ř. XSL 9. 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 CSS 10, 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šší extensible Stylesheet Language 10 Cascading Style Sheets - jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML.

25 2.7. JETTY 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, DHTML 12 a DOM 13 skriptování. Ext je postaven na přídavná rozšiřující knihovna YUI 14. 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 Dynamic HTML 13 Document Object Model 14 Yahoo! UI Library Oproti např. MySQL, která je zdarma pouze pro nekomerční použití

26 10 KAPITOLA 2. POUŽITÉ TECHNOLOGIE 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 ACID 17, 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)

27 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ů (TicketPortal 1, Ticket-Art 2, Ticket- Pro 3, Ticket-Stream 4 ) a samostatné vstupenkové systémy (Colosseum 3000, Pegas) 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ý 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 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

28 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 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

29 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: cenafinal = 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í.

30 14 KAPITOLA 3. ÚVODNÍ STUDIE 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 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

31 3.4. NEFUNKČNÍ POŽADAVKY 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 g. Délka vstupenek může být v rozsahu 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 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 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 tisku 7. 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 Výška je uváděna v palcích - omezeno pevnou výškou řádky tiskárny 7 Vysoká citlivost na teplo a světlo

32 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 Gemini Print Server JSServlet JDBC PostgreSQL Klient GPSServlet Database Server 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 Kategorie Odhad Dopad Nedostatečné nástroje pro vývoj Technologické 10 % Marginální Nekompatibilita HW a SW Technologické 10 % Zanedbatelný

33 3.6. ANALÝZA RIZIK 17 Riziko Kategorie Odhad Dopad Výkonnost HW a SW Technologické 20 % Marginální Chyby v analýze Procesní 20 % Kritický Odklon od požadavků Procesní 10 % Marginální Špatný odhad velikosti Procesní 30 % Kritický Nepochopení ovládání Implementační 20 % Kritický Znalosti použitých technologií Implementační 50 % Kritický Nedostatečné testování Implementační 40 % Kritický Chyba HW Bezpečnostní 10 % Katastrofický Chyba SW Bezpečnostní 20 % 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 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 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

34 18 KAPITOLA 3. ÚVODNÍ STUDIE 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 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 Š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 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 GUI 8. Řešitel: Řešitel, zákazník 8 Grafické uživatelské rozhranní

35 3.6. ANALÝZA RIZIK 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 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 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 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

36 20 KAPITOLA 3. ÚVODNÍ STUDIE

37 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

38 22 KAPITOLA 4. ANALÝZA ŘEŠENÍ 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 Role Akce 1 Systém Zobrazí přihlašovací stránku 2 Uživatel Zadá přihlašovací údaje 3 Systém Ověří platnost vložených údajů a přihlásí uživatele do systému 3a Systém 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 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

39 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 Role Akce 1 Systém Přijme požadavek na funkci systému 2 Systém Ověří platnost přihlášení a oprávnění ke spuštění funkce systému 3 Systém Provede funkci 3a Systém 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) 3b Systém 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 Autentizace uzivatele <<include>> Odhlaseni uzivatele Obrázek 4.4: Use Case: Odhlášení uživatele

40 24 KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.3: Use Case: Odhlášení uživatele Krok Role Akce 1 Uživatel Vybere možnost Odhlásit 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Odhlásí uživatele 4 Systém Zobrazí přihlašovací stránku (Use Case 4.1) Obrázek 4.5: Návrh GUI: Dialog přihlášení 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 Role Akce 1 Uživatel Odešle požadavek na změnu hesla 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí uživateli formulář pro změnu hesla 4 Uživatel Zadá staré a nové heslo 5 Systém Ověří platnost hesla a změní jej 5a Systém 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

41 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 25 System Autentizace uzivatele Smazani uzivatele <<include>> <<include>> Sprava uzivatelu <<include>> Seznam uzivatelu Uzivatel <<include>> <<include>> Pridani uzivatele <<include>> Zmena hesla Editace uzivatele Obrázek 4.6: Use Case: Správa uživatelů Tabulka 4.5: Use Case: Správa uživatelů Krok Role Akce 1 Uživatel Odešle požadavek na správu uživatelů 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Provede příslušný požadavek 3a Systém 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) 3b Systém Přijal požadavek na editaci uživatele: 3b1: Systém zahájí případ Editace uživatele (Use Case 4.7) 3c Systém 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) 3d Systém Přijal požadavek na smazání uživatele: 3d1: Systém zahájí případ Smazání uživatele (Use Case 4.9) 3e Systém Přijal požadavek na zobrazení seznamu uživatelů: 3e1: Systém zahájí případ Seznam uživatelů (Use Case 4.10) Přidání uživatele 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

42 26 KAPITOLA 4. ANALÝZA ŘEŠENÍ 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 Role Akce 1 Systém Přijme požadavek na přidání nového uživatele 2 Systém Zobrazí uživateli formulář pro zadání údajů uživatele 3 Uživatel Zadá údaje o uživateli 4 Systém Ověří platnost údajů a přídá uživatele 4a Systém 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 Role Akce 1 Systém Přijme požadavek na editaci uživatele 2 Systém 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 3 Uživatel Zadá údaje o uživateli 4 Systém Ověří platnost údajů a změní údaje uživatele 4a Systém 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

43 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 27 Tabulka 4.8: Use Case: Změna hesla uživatele Krok Role Akce 1 Systém Přijme požadavek na změnu hesla uživatele 2 Systém Zobrazí uživateli formulář pro změnu hesla vybraného uživatele 3 Uživatel Zadá nové heslo vybraného uživatele 4 Systém Ověří platnost hesla a změní jej u vybraného uživatele 4a Systém 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 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 Role Akce 1 Systém Přijme požadavek na smazání vybraného uživatele 2 Systém Smaže vybraného uživatele 2a Systém Uživatel nelze smazat (datová integrita): 2a1: Systém zobrazí informaci neprovedeném smazání

44 28 KAPITOLA 4. ANALÝZA ŘEŠENÍ 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 Role Akce 1 Systém Přijme požadavek na zobrazení seznamu uživatelů 2 Systém Zobrazí seznam uživatelů 2a Systém 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) 2b Systém 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) Smazání uživatele Zobrazení potvrzení smazání uživatele NE ANO Smazání uživatele Obrázek 4.10: Activity Diagram: Smazání uživatele Obrázek 4.11: Návrh GUI: Správa uživatelů

45 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 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 Autentizace uzivatele <<include>> 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 Role Akce 1 Uživatel Odešle požadavek na vytvoření nového zákazníka 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář pro zadání údajů 4 Uživatel Zadá údaje zákazníka 5 Systém Ověří platnost vložených údajů a přidá zákazníka do systému 5a Systém 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 neplatné údaje Zobrazení formuláře nového zákazníka Vyplnění údajů Kontrola údajů Vytvoření zákazníka Obrázek 4.13: Activity Diagram: Vytvoření zákazníka 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

46 30 KAPITOLA 4. ANALÝZA ŘEŠENÍ System Autentizace uzivatele Smazani zakaznika <<include>> Vyhledani zakaznika <<include>> Slouceni zakaznika Uzivatel <<include>> Editace zakaznika <<include>> Je-li povoleno Obrázek 4.14: Use Case: Vyhledání zákazníka Tabulka 4.12: Use Case: Vyhledání zákazníka Krok Role Akce 1 Uživatel Odešle požadavek na vyhledání zákazníka 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář pro zadání vyhledávacích kritérií 4 Uživatel Zadá vyhledávací kritéria 5 Systém Vyhledá zákazníky podle zadaných kritérií 6 Systém Zobrazí vyhledaný seznam zákazníků 6a Systém 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) 6b Systém 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) 6c Systém 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 Role Akce 1 Systém Přijme požadavek na smazání zákazníka 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Smaže vybraného uživatele 3a Systém Zákazník nelze smazat (datová integrita): 3a1: Systém zobrazí informaci neprovedeném smazání

47 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 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 Role Akce 1 Systém Přijme požadavek na editaci zákazníka 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém 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 4 Uživatel Zadá údaje o zákazníkovi 5 Systém Ověří platnost údajů a změní údaje zákazníka 5a Systém 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

48 32 KAPITOLA 4. ANALÝZA ŘEŠENÍ 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 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 Role Akce 1 Systém Přijme požadavek na sloučení zákazníka 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář pro zadání slučovaných zákazníků 4 Uživatel Vyplní formulář 5 Systém Ověří platnost údajů a provede sloučení 4a Zákazník 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

49 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 33 Sloučení zákazníka Zobrazení formuláře sloučení zákazníka Vyplnění údajů Vyhledání zákazníka Sloučení zákazníka Obrázek 4.18: Activity Diagram: Sloučení zákazníka 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 Autentizace uzivatele <<include>> Seznam akci <<extend>> Vyhledani akce Uzivatel <<include>> <<include>> Detail akce Vyber sedadel Obrázek 4.19: Use Case: Seznam akcí Tabulka 4.16: Use Case: Seznam akcí Krok Role Akce 1 Uživatel Odešle požadavek na Seznam akcí 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí seznam akcí 4 Uživatel Prohlíží seznam akcí

50 34 KAPITOLA 4. ANALÝZA ŘEŠENÍ Krok Role Akce 1a Uživatel Uživatel odešle požadavek na vyhledání akce: 1a1: Systém provede případ Vyhledání akce (Use Case 4.19) 4a Uživatel 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) 4b Uživatel 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í 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 Role Akce 1 Systém Přijme požadavek na výběr sedadel 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář s hledištěm k výběru sedadel 4 Uživatel Vybere sedadla k odeslání, včetně výběru slev 5 Systém Zkontroluje vkládaná sedadla a vloží je do nákupního košíku 5a Systém Sedadlo je již obsazeno: 5a1: Systém zobrazí informaci o obsazenosti sedadel a vyzve uživatele k opravě zadání (krok 3)

51 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 35 Výběr sedadel 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 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 Role Akce 1 Systém Přijme požadavek na zobrazení detailu akce 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí detail akce 4 Uživatel Prohlíží detail akce 4a Uživatel Uživatel vybere detail sedadla: 4a1: Systém zobrazí informaci o vybraném sedadle

52 36 KAPITOLA 4. ANALÝZA ŘEŠENÍ 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 Role Akce 1 Systém Přijme požadavek na vyhledání akce 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář pro zadání vyhledávacích kritérií 4 Uživatel Zadá vyhledávací kritéria 5 Systém Vyhledá akce podle zadaných kritérií 6 Systém Zobrazí vyhledaný seznam akcí 7 Uživatel Pokračuje případem Seznam akcí (Use Case 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 <<include>> Autentizace uzivatele Uzivatel <<include>> <<include>> 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 Role Akce 1 Uživatel Odešle požadavek na vytvoření nové legitimace 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí uživateli výběr typu legitimace 4 Uživatel Vybere typ legitimace 5 Systém Zpracuje požadavek uživatele

53 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 37 Krok Role Akce 5a Uživatel Uživatel vybere fixní typ předplatného: 5a1: Systém zpracuje vytvoření fixního předplatného (Use Case 4.21) 5b Uživatel 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 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 Role Akce 1 Systém Přijme požadavek na vytvoření legitimace 2 Systém Zobrazí formulář pro výběr sedadla 3 Uživatel Vybere sedadlo 4 Systém Vytvoří legitimaci fixního předplatného a vloží ji do košíku 4a Systém 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

54 38 KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.22: Use Case: Vytvoření volného předplatného Krok Role Akce 1 Systém Přijme požadavek na vytvoření legitimace 2 Systém Zobrazí formulář pro výběr cenové zóny 3 Uživatel Vybere cenovou zónu 4 Systém 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 Autentizace uzivatele Vyber zakaznika <<include>> <<include>> <<include>> Vytvoreni zakazky Nakupni kosik Uzivatel <<include>> Prohlizeni kosiku <<include>> <<include>> <<include>> Prodej kosiku Smazani kosiku Rezervace kosiku Obrázek 4.25: Use Case: Nákupní košík Tabulka 4.23: Use Case: Nákupní košík Krok Role Akce 1 Uživatel Odešle požadavek na práci z košíkem 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Provede příslušný požadavek

55 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 39 Krok Role Akce 3a Systém Přijal požadavek na prohlížení košíku: 3a1: Systém zahájí případ Prohlížení košíku (Use Case 4.24) 3b Systém Přijal požadavek na smazání košíku: 3b1: Systém zahájí případ Smazání košíku (Use Case 4.25) 3c Systém Přijal požadavek na rezervaci košíku: 3c1: Systém zahájí případ Rezervaci košíku (Use Case 4.26) 3d Systém Přijal požadavek na prodej košíku: 3d1: Systém zahájí případ Prodej košíku (Use Case 4.27) 3e Systém Přijal požadavek na vytvoření zakázky: 3e1: Systém zahájí případ Vytvoření zakázky (Use Case 4.28) 3f Systém 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 Role Akce 1 Systém Přijme požadavek na prohlížení košíku 2 Systém Zobrazí uživateli obsah košíku Obrázek 4.26: Návrh GUI: Vzhled košíku Smazání košíku Případ Smazání košíku slouží k odstranění obsahu košíku Aktéři: Systém

56 40 KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.25: Use Case: Smazání košíku Krok Role Akce 1 Systém Přijme požadavek na smazání košíku 2 Systém 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 Role Akce 1 Systém Přijme požadavek na rezervaci 2 Systém Zobrazí uživateli formulář pro zadání rezervace 3 Uživatel Zadá údaje o rezervaci 4 Systém Ověří platnost údajů a vytvoří rezervace 5 Systém Zarezervované vstupenky odstraní z košíku 4a Systém 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 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

57 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 41 Tabulka 4.27: Use Case: Prodej košíku Krok Role Akce 1 Systém Přijme požadavek na prodej 2 Systém Zobrazí uživateli formulář pro zadání údajů prodeje 3 Uživatel Zadá údaje o prodeji (volba platby) 4 Systém Prodá položky košíku a košík vyčistí 5 Systém 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 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

58 42 KAPITOLA 4. ANALÝZA ŘEŠENÍ Tabulka 4.28: Use Case: Vytvoření zakázky Krok Role Akce 1 Systém Přijme požadavek na vytvoření zakázky 2 Systém Zobrazí uživateli formulář pro zadání údajů zakázky 3 Uživatel Zadá údaje o zakázce 4 Systém Ověří platnost údajů a vytvoří zakázku 4a Systém 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) Vytvoření zakázky neplatné údaje Zobrazení formuláře vytvoření zakázky Vyplnění údajů Kontrola údajů Vytvoření zakázky Obrázek 4.30: Activity Diagram: Vytvoření zakázky Obrázek 4.31: Návrh GUI: Prodej košíku 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

59 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 43 Tabulka 4.29: Use Case: Výběr zákazníka Krok Role Akce 1 Systém Přijme požadavek na výběr zákazníka 2 Systém Zobrazí uživateli formulář pro vyhledání zákazníka (Use Case 4.12) 3 Uživatel Vybere zákazníka 4 Systém 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 Autentizace uzivatele Vyhledani zakazky Zakazka otevrena Uzivatel 1 1 <<include>> Seznam zakazek <<include>> Storno zakazky <<extend>> Editace zakazky <<include>> <<include>> <<include>> Vystaveni dokladu Vyber zakaznika <<include>> Vyhledani zakaznika Obrázek 4.32: Use Case: Seznam zakázek Tabulka 4.30: Use Case: Správa zakázek Krok Role Akce 1 Uživatel Odešle požadavek na Seznam zakázek 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí seznam zakázek 4 Uživatel Prohlíží seznam zakázek 1a Uživatel 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) 4a Uživatel Uživatel odešle požadavek na storno zakázky: 4a1: Systém provede případ Storno zakázky (Use Case 4.32)

60 44 KAPITOLA 4. ANALÝZA ŘEŠENÍ Krok Role Akce 4b Uživatel 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 Role Akce 1 Systém Přijme požadavek na vyhledání zakázky 2 Systém Ověří totožnost uživatele (Use Case 4.2) 3 Systém Zobrazí formulář pro zadání vyhledávacích kritérií 4 Uživatel Zadá vyhledávací kritéria 5 Systém Vyhledá akce podle zadaných kritérií 6 Systém Zobrazí vyhledaný seznam zakázek 7 Uživatel Pokračuje případem Seznam zakázek (Use Case krok 4) Vyhledání / Seznam zakázky vyhledání Zobrazení formuláře vyhledání zakázky Vyplnění údajů Vyhledání zakázek seznam Načtení zakázek Zobrazení zakázek Obrázek 4.33: Activity Diagram: Vyhledání / Seznam zakázky 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

61 4.2. ANALÝZA PŘÍPADŮ POUŽITÍ 45 Tabulka 4.32: Use Case: Storno zakázky Krok Role Akce 1 Systém Přijme požadavek na storno zakázky 2 Systém Zobrazí uživateli formulář pro stornování zakázky 3 Uživatel Vyplní formulář (typ platby) 4 Systém Vystornuje zakázku 5 Systém 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 Role Akce 1 Systém Přijme požadavek na editaci zakázky 2 Systém Zobrazí uživateli formulář pro editaci zakázky 3 Uživatel Prohlíží podrobnosti zakázky ve formuláři editace zakázky 3a Uživatel 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) 3b Uživatel 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 Výběr zákazníka uložení zakázky ANO Uložení zakázky Načtení formuláře editace zakázky akce vystavení dokladu Načtení dialogu vystavení dokladu Zadání parametrů NE Vystavení dokladu Obrázek 4.34: Activity Diagram: Editace zakázky

62 46 KAPITOLA 4. ANALÝZA ŘEŠENÍ Obrázek 4.35: Návrh GUI: Editace zakázky 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 Role Akce 1 Systém Přijme požadavek na vystavení dokladu 2 Systém Zobrazí uživateli formulář pro vystavení dokladu 3 Uživatel Zadá parametry vystavovaného dokladu 4 Systém Vytvoří zaúčtování a doklad 1a Uživatel 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

63 4.3. KONCEPTUÁLNÍ DATOVÝ MODEL 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..* * 0..* 0..* hlediste 0..* 1 1 predstaveni 0..* navstevy 1 abonma 1 doklady 1 1..* rezervace 1 0..* 1..* akce 0..* typy 0..* 0..* zony 1 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.

64 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.

65 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

66 50 KAPITOLA 5. NÁVRH A IMPLEMENTACE Obrázek 5.1: ER Diagram

67 5.1. FYZICKÝ DATOVÝ MODEL 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 Název Typ Null Default PK id abonma SERIAL NO FK id typu INTEGER NO FK id zony INTEGER NO FK id zakazky INTEGER NO aktivni BOOLEAN YES true id sedadla INTEGER YES cislo VARCHAR(16) YES cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO dph typ SMALLINT NO 0 FK id uzivatele INTEGER NO dt TIMESTAMP NO 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 Název Typ Null Default PK id typu SERIAL NO typ ab typy NO nazev VARCHAR(32) NO dt od DATE NO dt do DATE NO FK id hlediste INTEGER YES 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).

68 52 KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.3: Databázová tabulka: abonmatypyd Key Název Typ Null Default PK id typud SERIAL NO FK id typu INTEGER NO nazev VARCHAR(32) NO voucher BOOLEAN NO false inverze BOOLEAN NO false FK id akce INTEGER YES FK typ akce INTEGER YES Tabulka abonmazony obsahuje seznam cenových zón k danému typu předplatného. Tabulka 5.4: Databázová tabulka: abonmazony Key Název Typ Null Default PK id zony INTEGER NO FK id typu INTEGER NO nazev VARCHAR(32) NO 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 Název Typ Null Default FK id zony INTEGER NO FK id typud INTEGER NO cenax DECMAL(8,2) YES k DECMAL(5,2) NO 1 q DECMAL(8,2) NO 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 Název Typ Null Default PK id abonmad SERIAL NO

69 5.1. FYZICKÝ DATOVÝ MODEL 53 Key Název Typ Null Default FK id abonma INTEGER NO FK id zakazky INTEGER NO aktivni BOOLEAN YES true cislo VARCHAR(16) YES FK id predstaveni INTEGER YES id sedadla INTEGER YES cena DECIMAL(8,2) NO 0 cena dph DECIMAL(8,2) NO 0 zaloha DECIMAL(8,2) NO zaloha dph DECIMAL(8,2) NO dph typ SMALLINT NO 0 FK id uzivatele INTEGER NO dt TIMESTAMP NO 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 Název Typ Null Default PK id akce SERIAL NO FK id hlediste INTEGER NO FK id predstaveni INTEGER NO aktivni BOOLEAN NO true uzamceno BOOLEAN NO false neadresni mista INTEGER NO 0 export stav SMALLINT NO 0 poznamka VARCHAR(16) YES sync ts TIMESTAMP NO 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 Název Typ Null Default FK id akce INTEGER NO FK id kategorie INTEGER NO k DECIMAL(5,2) NO 1 q DECIMAL(8,2) NO 0 slevy BOOLEAN NO false

70 54 KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka akcedata obsahuje volitelné údaje o akci, je použito schéma klíč-hodnota. Tabulka 5.9: Databázová tabulka: akcedata Key Název Typ Null Default FK id akce INTEGER NO FK klic VARCHAR(16) NO hodnota VARCHAR(64) NO Vazební tabulka akceslevy obsahuje povolené slevy pro vybranou akci. Tabulka 5.10: Databázová tabulka: akceslevy Key Název Typ Null Default FK id akce INTEGER NO FK id slevy INTEGER NO Vazební tabulka akcetypy obsahuje seznam, jakých typů je daná akce. Tabulka 5.11: Databázová tabulka: akcetypy Key Název Typ Null Default FK id akce INTEGER NO FK id typu INTEGER NO 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 Název Typ Null Default PK id akce SERIAL NO PK id sedadla INTEGER NO stav akced stavy NO volno cena DECIMAL(8,2) NO -1 barva VARCHAR(6) NO ffffff

71 5.1. FYZICKÝ DATOVÝ MODEL 55 Key Název Typ Null Default FK id blokace INTEGER NO 0 sync ts TIMESTAMP NO CURRENT TIMESTAMP Tabulka blokace obsahuje seznam blokací. Tabulka 5.13: Databázová tabulka: blokace Key Název Typ Null Default PK id blokace INTEGER NO nazev VARCHAR(32) NO barva VARCHAR(6) YES aktivni BOOLEAN YES 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 Název Typ Null Default FK id blokace INTEGER NO FK id uzivatele INTEGER NO 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 Název Typ Null Default PK id dokladu SERIAL NO FK id zakazky INTEGER NO FK id platby INTEGER YES typ doklady typy NO typ platby platby typy NO aktivni BOOLEAN YES true cislo VARCHAR(16) YES faddr0 VARCHAR(126) YES faddr1 VARCHAR(64) YES faddr2 VARCHAR(64) YES

72 56 KAPITOLA 5. NÁVRH A IMPLEMENTACE Key Název Typ Null Default faddr3 VARCHAR(8) YES fstat VARCHAR(32) YES dt vystaveni TIMESTAMP NO CURRENT TIMESTAMP dt dph DATE YES dt splatnost DATE YES cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO text VARCHAR(1024) YES FK id uzivatele TIMESTAMP NO Tabulka hlediste obsahuje seznam povolených hledišť, včetně jejich parametrů. Tabulka 5.16: Databázová tabulka: hlediste Key Název Typ Null Default id hlediste SERIAL NO nazev VARCHAR(32) NO kod VARCHAR(8) NO src VARCHAR(32) NO max s INTEGER NO 0 max m INTEGER NO 0 popis VARCHAR(128) YES aktivni BOOLEAN NO 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 Název Typ Null Default PK,FK id hlediste INTEGER NO PK id sedadla INTEGER NO FK id sektoru INTEGER YES a VARCHAR(8) YES b VARCHAR(8) YES extra VARCHAR(32) YES poradi INTEGER NO 0

73 5.1. FYZICKÝ DATOVÝ MODEL 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 Název Typ Null Default PK id sektoru SERIAL NO FK id hlediste INTEGER NO nazev VARCHAR(64) NO a txt VARCHAR(16) YES b txt VARCHAR(16) YES 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 Název Typ Null Default PK id hry SERIAL NO nazev VARCHAR(64) NO popis VARCHAR(128) YES aktivni BOOLEAN NO true repertoar BOOLEAN NO false Tabulka hrydata obsahuje volitelné údaje o hře, je použito schéma klíč-hodnota. Tabulka 5.20: Databázová tabulka: hrydata Key Název Typ Null Default FK id hry INTEGER NO FK klic VARCHAR(16) NO hodnota VARCHAR(64) NO Vazební tabulka hrytypy obsahuje seznam, jakých typů je daná hra. Tabulka 5.21: Databázová tabulka: hrytypy Key Název Typ Null Default FK id hry INTEGER NO FK id typu INTEGER NO

74 58 KAPITOLA 5. NÁVRH A IMPLEMENTACE 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 Název Typ Null Default PK id kontaktu SERIAL NO FK id kategorie INTEGER YES uid VARCHAR(16) YES titul VARCHAR(16) YES jmeno VARCHAR(32) YES prijmeni VARCHAR(64) YES organizace VARCHAR(64) YES ico VARCHAR(16) YES dic VARCHAR(16) YES addr0 VARCHAR(126) YES addr1 VARCHAR(64) YES addr2 VARCHAR(32) YES addr3 VARCHAR(8) YES stat VARCHAR(32) YES faddr0 VARCHAR(126) YES faddr1 VARCHAR(64) YES faddr2 VARCHAR(64) YES faddr3 VARCHAR(8) YES fstat VARCHAR(32) YES tel1 VARCHAR(32) YES tel2 VARCHAR(32) YES telf VARCHAR(32) YES VARCHAR(126) YES banka1 VARCHAR(64) YES banka2 VARCHAR(32) YES poznamka VARCHAR(4096) YES 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 Název Typ Null Default PK id platby SERIAL NO FK id zakazky INTEGER NO

75 5.1. FYZICKÝ DATOVÝ MODEL 59 Key Název Typ Null Default aktivni BOOLEAN NO true smer platby smery NO typ platby typy NO dt platby DATE NO CURRENT DATE cena DECIMAL(8,2) NO vs VARCHAR(16) YES FK id uzivatele INTEGER NO 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 Název Typ Null Default PK id pracoviste SERIAL NO nazev VARCHAR(32) NO aktivni BOOLEAN NO 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 Název Typ Null Default PK id predstaveni SERIAL NO FK id akce INTEGER NO FK id hry INTEGER NO cas DATETIME NO 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).

76 60 KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.26: Databázová tabulka: prodeje Key Název Typ Null Default PK id prodeje SERIAL NO FK id zakazky INTEGER NO FK id predstaveni INTEGER NO id sedadla INTEGER NO aktivni BOOLEAN NO true cenax DECIMAL(8,2) NO cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO dph typ SMALLINT NO 0 FK id slevy INTEGER YES FK id uzivatele INTEGER NO dt TIMESTAMP NO 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 Název Typ Null Default PK id rezervace SERIAL NO FK id predstaveni INTEGER NO jmeno VARCHAR(32) dt vyprseni TIMESTAMP poznamka VARCHAR(255) aktivni BOOLEAN NO true pocet INTEGER NO cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO FK id uzivatele INTEGER NO dt TIMESTAMP NO CURRENT TIMESTAMP Tabulka rezervaced obsahuje jednotlivá sedadla patřící rezervaci určené v id rezervace. Tabulka 5.28: Databázová tabulka: rezervaced Key Název Typ Null Default PK,FK id rezervace INTEGER NO FK id sedadla INTEGER NO cenax DECIMAL(8,2) NO

77 5.1. FYZICKÝ DATOVÝ MODEL 61 Key Název Typ Null Default cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO id slevy INTEGER YES aktivni BOOLEAN NO 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 Název Typ Null Default PK id role SERIAL NO nazev VARCHAR(32) NO popis VARCHAR(64) YES 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 Název Typ Null Default PK,FK id role INTEGER NO PK opravneni VARCHAR(64) NO 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 Název Typ Null Default PK id sabonma SERIAL NO FK id zakazky INTEGER NO FK id dokladu INTEGER YES FK id abonma INTEGER NO cena DECIMAL(8,2) NO cena dph DECIMAL(8,2) NO dph typ SMALLINT NO 0 FK id uzivatele INTEGER NO dt TIMESTAMP NO CURRENT TIMESTAMP

78 62 KAPITOLA 5. NÁVRH A IMPLEMENTACE 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 Název Typ Null Default PK id sabonmad SERIAL NO FK id zakazky INTEGER NO FK id dokladu INTEGER YES FK id abonmad INTEGER NO FK id uzivatele INTEGER NO dt TIMESTAMP NO 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 cenafinal = k cena + q. Tabulka 5.33: Databázová tabulka: slevy Key Název Typ Null Default PK id slevy SERIAL NO nazev VARCHAR(32) NO aktivni BOOLEAN NO true k DECIMAL(5,2) NO 1 q DECIMAL(8,2) NO 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 Název Typ Null Default PK id sprodeje SERIAL NO FK id zakazky INTEGER NO FK id dokladu INTEGER YES FK id prodeje INTEGER NO FK id uzivatele INTEGER NO dt TIMESTAMP NO CURRENT TIMESTAMP

79 5.1. FYZICKÝ DATOVÝ MODEL 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 Název Typ Null Default PK id uzivatele SERIAL NO FK id role INTEGER NO auth name VARCHAR(32) NO auth pass VARCHAR(32) NO jmeno VARCHAR(32) YES aktivni BOOLEAN NO true FK id pracoviste INTEGER NO persistentni sid BOOLEAN NO 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 Název Typ Null Default PK id vstupenky SERIAL NO FK id prodeje INTEGER NO barcode VARCHAR(10) YES aktivni BOOLEAN NO true duplikat BOOLEAN NO false FK id uzivatele INTEGER NO dt TIMESTAMP NO 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.

80 64 KAPITOLA 5. NÁVRH A IMPLEMENTACE Tabulka 5.37: Databázová tabulka: zakazky Key Název Typ Null Default PK id zakazky SERIAL NO FK id kontaktu INTEGER YES cislo VARCHAR(10) YES stav zakazky typy NO kosik cena DECIMAL(8,2) NO 0 cena dph DECIMAL(8,2) NO 0 zaplaceno DECIMAL(8,2) NO 0 stornovano DECIMAL(8,2) NO 0 FK id uzivatele INTEGER NO dt vytvoreni TIMESTAMP NO 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.

81 5.1. FYZICKÝ DATOVÝ MODEL 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.

82 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 GUI 1. 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 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í

83 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 Package cz.comnet.gemini.cronlib Do tohoto package patří všechny třídy, které je možné volat z třídy Cron.

84 68 KAPITOLA 5. NÁVRH A IMPLEMENTACE 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) 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.

85 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.

86 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

87 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 "Správa Správa akcí" /pkg/sprava/akce#akce akce.getlist // menu "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).

88 72 KAPITOLA 5. NÁVRH A IMPLEMENTACE <group> <common> </common> <item> </item> <item> </item>... </group>

89 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í 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 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 Někdy též nazýváno jako glass-box, clear-box, logic-driven testing 2 Někdy též nazýváno jako functional, data-driven, input-output driven testing 73

90 74 KAPITOLA 6. TESTOVÁNÍ 6.2 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ší.

91 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 PHP 1, 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 ( 75

92 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.

93 Literatura [1] M. M. Hana Kanisová. UML srozumitelně. Computer Press, 2. aktualizované vydání, [2] S. Holzner. XSLT: příručka internetového vývojáře. Computer Press, [3] S. Holzner. Mistrovství v Ajaxu. Computer Press, [4] M. Šimůnek. SQL: Kompletní kapesní průvodce. Grada, [5] J. P. Ivan Halaška. Databázové systémy. Vydavatelství ČVUT, 2. vydání, [6] J. Kosek. HTML: tvorba dokonalých www stránek. Grada, [7] B. Momjian. PostgreSQL - Praktický průvodce. Computer Press, [8] J. Resig. JavaScript a Ajax. Computer Press, [9] B. Spell. JAVA: programujeme profesionálně. Computer Press, [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

94 78 LITERATURA

95 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 nebo novější) A.2 Instalace podpůrných aplikací 1. Instalace JRE 1 6 Nainstalujte podporu pro běh aplikací JRE (verze Java SE), volně ke stažení na nebo ve Vaší distribuci Linuxu. 2. Instalace PostgreSQL 8.3 Nainstalujte databázi PostgreSQL, volně ke stažení na 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

96 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 Web- Ticket), 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í em), 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í em. 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/.

97 A.4. INSTALACE GPS SERVERU 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í

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

99 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í (JRE 1 ) a dodaný jednoduchý program GPS (Gemini Print Server). Pro přihlášení do systému zadáváme do prohlížeče 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

100 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 řádku 2. 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í

101 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ě-

102 86 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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

103 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í

104 88 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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 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 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)

105 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 Š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 Ú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.

106 90 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA B 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.

107 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.

108 92 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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é: cenafinal = 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č Sleva 10% + 10 Kč příplatek 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.

109 B.3. SPRÁVA SYSTÉMU 93 B.3.5 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 WebTicket 3 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 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

110 94 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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 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.

111 B.3. SPRÁVA SYSTÉMU 95 Obrázek B.12: Dialog Nastavení blokace B 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 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

112 96 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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

113 B.3. SPRÁVA SYSTÉMU 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.

114 98 PŘÍLOHA B. UŽIVATELSKÁ PŘÍRUČKA 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í.

115 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í