Fakulta elektrotechnická. Bc. Petr Halaška. Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Informační systém ubytovacího zařízení Bc. Petr Halaška Vedoucí práce: Ing. Radek Malinský Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 15. května 2011

2 iv

3 v Poděkování Rád bych poděkoval Ing. Radkovi Malinskému za vedení mé diplomové práce, za jeho čas a cenné rady. Dále také své rodině a přátelům za veškerou podporu během celého studia.

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

6 viii

7 Abstract The thesis deals with the implementation of information system designed for hotels and other lodging facilities. The primary objective of the resulting application is a comprehensive report of the booking and other coherent matters. The first part is concerned with a search of available products on the market. Further is the work focused on the analysis maintaining the bachelor thesis and the overview of used technologies. Following chapter is analyzing implementation and operating procedure working with the Java Enterprise Edition. The last chapters describe the process of testing the created prototype, and the final summary of the whole thesis. Abstrakt Tato diplomová práce se zabývá realizací informačního systému určeného pro hotely a jiná ubytovací zařízení. Primárním cílem výsledné aplikace je komplexní správa rezervací a s tím spojených všech záležitostí. První část je věnována rešerši dostupných produktů na trhu. Práce pokračuje analýzou, ve které se dočteme, jakým způsobem je navázáno na bakalářskou práci a návrhem přinášejícím především přehled použitých technologií. Následuje rozbor implementace a způsob práce pod platformou Java Enterprise Edition. V posledních kapitolách je popsán způsob testování vzniklého prototypu a závěrečné shrnutí celé diplomové práce. ix

8 x

9 Obsah 1 Úvod Obsah kapitol Popis problému, specifikace cíle 3 3 Rešerše existujících produktů Sledované vlastnosti Provoz a funkcionalita Finance Přehledy, vyhodnocení, grafy Technologie Použitelnost Propagace, úspěšnost Cena Popis vybraných systémů Souhrnná tabulka Vyhodnocení Analýza Původní aplikace Funkční a nefunkční požadavky Definice uživatelských rolí Případy užití Konceptuální datový model Návrh řešení Výběr implementačního prostředí Java Enterprise Edition Java Server Faces Managed Beans Navigace Konverze Validace Životní cyklus Java Server Faces JSF Enterprise Java Beans (EJB) xi

10 xii OBSAH Java Persistance API PrimeFaces itext Diagram komponent Diagram nasazení Realizace Počáteční konfigurace Databáze EJB modul Model Session Beans Zabezpečení Konfigurace projektu Konfigurace Glassfish Přihlašovací stránka Šablonovací systém Import PrimeFaces do projektu Internacionalizace Modul spravující nastavení systému Modul rezervace Zobrazení rezervací Kalkulace Kniha hostů Online rezervace Captcha Grafy a přehledy Export do PDF Testovací data Testování Cíle testování Cílová skupina Příprava testování Screener Pre-test Post-test Scénář úkolů Nastavení testu Provedení testů Shrnutí průchodu jednotlivými úkoly Post-test Vyhodnocení testů Hypotézy Návrhy na možná vylepšení aplikace

11 OBSAH xiii 8 Závěr 55 A Seznam použitých zkratek 59 B Tabulky vlastností porovnávaných produktů 61 B.1 ABX recepce B.2 DeCe Hotel B.3 Micros Fidelio Suite B.4 Hores B.5 Hotel-Keeper B.6 Mefisto B.7 Previo B.8 Savarin B.9 smarthotel (smartpension) C Dotazníky 69 C.1 Screener C.2 Pre-test C.3 Post-test D Scénář úkolů 73 E Uživatelská příručka 75 E.1 Instalační manuál E.1.1 Postup instalace na lokální server využitím NetBeans E Databáze E Nastavení Secure Realms na serveru Glassfish E Spuštění aplikace E.1.2 Manuální konfigurace na lokálním serveru Glassfish E Databáze E JDBC Connection Pools, JDBC Resources E Secure Realms E Spuštění aplikace E.1.3 Naplnění databáze testovacími daty E.2 Uživatelský manuál E.2.1 Přihlášení se do systému E.2.2 Výběr jazyka E.2.3 Přehled položek v menu E.2.4 Rezervace E Plachta rezervací E Vytvoření nové objednávky E Přehled objednávek E Online rezervace E.2.5 Hosté E.2.6 Pokladna E Faktury

12 xiv OBSAH E Pokladní kniha E.2.7 Statistiky, grafy E Výnosy, příjmy E Obsazenost E Zboží a služby E.2.8 Personál E.2.9 Nastavení systému E Informace o hotelu E Kategorie hostů E Partneři E Sezóny E Stravování E Zboží E Služby E Typy pokojů E Pokoje E Vybavení E.2.10 Nápověda E.2.11 Rezervační formulář na stránkách hotelu F Obsah přiloženého CD 93

13 Seznam obrázků 4.1 Uživatelské role Konceptuální datový model Strom komponent v JSF Statická navigace v JSF Dynamická navigace v JSF Architektura více-vrstvé aplikace Životní cyklus Stateful Session Beany Životní cyklus Stateless Session Beany Primefaces kalendář Automatické dokončování Datová tabulka v PrimeFaces Galerie obrázků PrimeFaces Diagram komponent Diagram nasazení Captcha E.1 Vytvoření databáze Java DB v NetBeans E.2 Přihlašovací stránka serveru Glassfish E.3 Security Realms E.4 JDBC Connection Pool E.5 Naplnění testovacími daty E.6 Přihlášení se do systému E.7 Volba jazyka E.8 Menu E.9 Plachta rezervací E.10 Náhled rezervace E.11 Nová objednávka vyplnění zákazníka E.12 Nová objednávka výběr z již uložených zákazníků E.13 Nová objednávka potvrzení E.14 Tabulka objednávek E.15 Editace objednávky E.16 Faktura E.17 Komponenta pro převod objednávek E.18 Graf obsazenosti pokojů xv

14 xvi SEZNAM OBRÁZKŮ E.19 Graf poskytovaných služeb E.20 Zaměstnanci E.21 Formulář online rezervace

15 Seznam tabulek 3.1 Souhrnná tabulka rešerše existujících produktů na trhu B.1 ABX recepce B.2 DeCe Hotel B.3 Micros Fidelio Suite B.4 Hores B.5 Hotel-Keeper B.6 Mefisto B.7 Previo B.8 Savarin B.9 SmartHotel (SmartPension) xvii

16 xviii SEZNAM TABULEK

17 Kapitola 1 Úvod Již podle názvu si každý může lehce udělat představu, o čem tato práce pojednává. Informační systém ubytovacího zařízení, jinými slovy systém, který uchovává a zpracovává informace týkající se provozu a správy hotelu nebo jiného ubytovacího zařízení. V dnešní době jsou podobné IS téměř v každém odvětví lidské činnosti. Všude tam kde je záhodno ukládat již zmíněné informace do databáze. Vytvořená aplikace v rámci této práce není proto jediná ve svém oboru, ale i tak přináší do prostředí hotelových aplikací odlišná řešení a možnosti. Z hlediska toho co by takový systém měl a mohl poskytovat, se otevírá poměrně široké pole, protože od nepaměti si každý hotel musí udržovat velké množství informací nutných pro svou správu, tak i ze zákona vynucených. Navíc, i dnes nalezneme mnoho podniků, které si vše zaznamenávají sice třeba již v digitální formě, ale bez použití nějakého sofistikovaného programu. Proto podle mého názoru je tvorba tohoto systému velmi aktuální a perspektivní téma, co se týče budoucnosti. Mimo jiné hlavní motivací při výběru tohoto tématu pro mě bylo dokončení projektu, který jsem započal jako bakalářskou práci [11] a vytvořit tak informační systém, který bude obsahovat všechny původně plánované funkce, které byly vzhledem k rozsahu neimplementované. V případě úspěšné realizace se v budoucnosti také naskýtá možnost otestovat výslednou aplikaci i v reálném prostředí hotelu zprostředkovanou přes kolegu Petra Vůjtěcha, od kterého vznikla prvotní myšlenka a vytvořil bakalářskou práci Analýza informačního systému pro ubytovací zařízení [14]. 1.1 Obsah kapitol Struktura práce je rozdělena do několika kapitol začínající tímto úvodem. V druhé kapitole je blíže specifikováno zadání práce a popsán problém, který bude hlavním předmětem zájmu při vypracovávání. Třetí kapitola srovnává již existující produkty na českém trhu. Nejprve je provedena analýza dostupnosti, podle které je poté vybráno devět hotelových systémů. Ty jsou porovnávány z hlediska určených kritérií a na základě získaných informací jsou vyhodnoceny závěry. 1

18 2 KAPITOLA 1. ÚVOD V následující čtvrté je zpracována analýza projektu. Zde jsou hlavně určeny všechny požadavky na systém, uživatelské role a konceptuální datový model. Pátá kapitola pojednává o návrhu řešení, blíže se tak přibližuje konkrétní realizaci a tomu jakým způsobem bude aplikace implementována. Vlastní implementace je popsána v navazující šesté kapitole, kde jsou vyzdviženy především důležité části, specifika a problémy při programování. Při vývoji takto rozsáhlejší aplikace je zapotřebí ji také důkladněji otestovat a to i za přispění nezávislých uživatelů. I tento požadavek není opomenut a vše je zaznamenáno v kapitole sedmé. Závěrem jsou shrnuty výsledky, diskuse, zda práce splnila vytyčené cíle, návrhy na různá vylepšení a možnosti dalšího pokračování. Součástí této diplomové práce jsou také přílohy, ve kterých můžeme nalézt uživatelskou příručku, rešeršní tabulky a dotazníky pro testování.

19 Kapitola 2 Popis problému, specifikace cíle Práce má za cíl navrhnout a vytvořit webový systém, který bude podporovat řízení hotelu nebo jiného ubytovacího zařízení. Bude určen pro uživatele, kteří v hotelu zodpovídají především za správu rezervací a interakci se zákazníkem, tj. recepční, ale také pro osoby, které řídí celý chod podniku, což může být i majitel. Systém poběží na webovém aplikačním serveru a zároveň bude přistupovat do databáze, umístěné podle předpokladů na stejném stroji. Z toho vyplývá, že uživatel pro práci s programem potřebuje pouze webový prohlížeč. Do systému se bude přihlašovat pomocí uživatelského účtu, díky němuž se přiřadí odpovídající role. Hlavní funkcionalitou aplikace bude správa objednávek, resp. organizace rezervací jednotlivých pokojů. S tím souvisí evidence dalších informací jako například knihy hostů, požadavků na stravování, prodej služeb a zboží. Nechybí ani správa pokojů a vybavení. Výstup z aplikace bude zajištěn ve formě exportu do pdf 1 nebo také různými přehledy ve formě grafů. Podrobný seznam funkcí a požadavků na systém je uveden v kapitole 4 Analýza. Při implementaci budou využity moderní technologie pro vývoj webových aplikací. Důležité je také jednoduché ovládání a intuitivní uživatelské prostředí, které se bude prověřovat pomocí experimentálního testování použitelnosti s participanty. Jak bylo řečeno v úvodu, protože toto téma již bylo zpracováváno v rámci bakalářské práce, systém tohoto rázu už existuje. V analýze je proto tento původní systém popsán a vyvozeno rozhodnutí, zda pokračovat v jeho vývoji nebo navrhnout nový. 1 PDF (Portable Document Format) souborový formát pro ukládání dokumentů nezávislých na hardwarovou či softwarovou platformu. Za jeho vznikem stojí společnost Adobe. 3

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

21 Kapitola 3 Rešerše existujících produktů Výsledný software by měl být dostatečně komplexní, aby dokázal pokrýt většinu procesů v hotelu. Častokrát bývá také propojen s dalšími systémy, jako například restauračními nebo účetními. V současné době existuje řada informačních systémů tohoto rázu. Cílem rešerše je získání přehledu o trhu s hotelovými systémy, tyto produkty sledovat, rozebrat a porovnat jejich vlastnosti. Ze zjištěných poznatků se v pak pokusíme odpovědět, zda a proč je příhodné vytvářet vlastní systém, v čem se bude od ostatních odlišovat a co přinese nového, aby se dokázal na trhu prosadit. V následujících odstavcích je podrobněji popsána skupina softwarových systémů pro ubytovací zařízení. Pro tento užší výběr produktů při internetovém vyhledávání byly stanoveny následující klíčové požadavky: Grafické uživatelské rozhraní. Správa objednávek, rezervací a s tím související finanční kalkulace. Administrace pokojů. Vedení databáze hostů. Manažerské přehledy, popř. grafy. Součástí systému další moduly (poskytující správu a řízení dalších činností v hotelu). 3.1 Sledované vlastnosti U vybraných hotelových systémů byly sledovány jako hlavní kritéria vlastnosti týkající se provozu a funkcionality, dále správa financí, souhrny a vyhodnocení pomocí různých grafů, způsob jak byly implementovány, jejich propagace, reklama, úspěšnost na trhu a v neposlední řadě také jejich cena. Kompletní výpis vlastností, na které se zaměříme: 5

22 6 KAPITOLA 3. REŠERŠE EXISTUJÍCÍCH PRODUKTŮ Provoz a funkcionalita Recepce modul pro správu a koordinaci rezervací, obsahuje základní funkce hotelového systému jako přidělování jednotlivých pokojů hostům apod. Správa vybavení možnost přehledu o vybavení na jednotlivých pokojích, například tv, stůl, křeslo. Uživatelské účty účet každého uživatele, který se systémem pracuje, díky nim lze přistupovat do aplikace jen přes zabezpečený vstup. Správa personálu hotelu tato funkce umožňuje jednoduchý přehled o dalších zaměstnancích nejen o těch, kteří se systémem pracují, ale také o pokojských, údržbářích atd. Modul restaurace hotel častokrát svým hostům také nabízí stravování. Může být řešeno sofistikovanějším programem, který celou restauraci řídí a nebo alespoň zda host má k pobytu zaplacenu například polopenzi. Online rezervace potencionální zákazník si může přes webové stránky prezentace hotelu prohlédnout obsazenost na určité období, či provést přímo předběžnou rezervaci díky spojení s hlavní aplikací. Další moduly hotel ke svému běhu taktéž potřebuje evidenci dalších svých aktivit, do kterých můžeme započítat drobný prodej zboží v recepci, nabídka služeb jako je zapůjčení kola, vstup do sauny, bazénu apod., součástí také může být modul pro skladové hospodářství. Speciální funkce sem spadají například integrace s elektronickými zámkovými systémy, pay Tv, telefonními ústřednami, řízení energií a další Finance Pokladna v této části probíhá kalkulace všech peněz v systému, ubytovací zařízení tak přehledně může evidovat tok finančních prostředků. Tisk, export faktur týká se nejen faktur pro zákazníka, ale také je důležitý tisk knihy hostů do písemné formy, což je dáno zákonem. Přepočet na cizí měny (směnárna) převody měn podle definovaných nebo automatických aktuálních kurzů. Podpora spolupráce s ubytovacími servery, partnery započítání provize za zprostředkovanou reklamu, zejména pak za každého takto získaného hosta.

23 3.1. SLEDOVANÉ VLASTNOSTI Přehledy, vyhodnocení, grafy Pro efektivní řízení podniku jsou přínosné různé manažerské souhrny a grafy, například obsazenosti pokojů během sezón a podobně Technologie Webová aplikace kritérium zda se jedná o desktopovou či webovou aplikaci. Možnost propojení hotelový resp. rezervační systém nemusí umět úplně vše, proto je výhoda, když máme možnost systém propojit s jiným softwarem, např. pro účetnictví. Propojení několika poboček hoteliér může vlastnit více zařízení, proto je žádoucí sít ové spojení hotelových systému. Jednoduché to je v případě, že se jedná o webovou aplikaci, která běží na nějakém serveru, ohledně desktopových platforem, může být propojení zajištěno sdílenou databází Použitelnost Jednoduché ovládání každý porovnávaný produkt byl prezentován svými tvůrci jako jednoduchý na ovládání. Pro toto kritérium nebyly vytvořeny žádné usability testy, proto se jedná pouze o subjektivní hodnocení autora této práce Propagace, úspěšnost Demoverze možnost zda je od výrobce k dispozici demoverze. Zákazník si tak může vyzkoušet program ještě před jeho zakoupením a zvážit tak tuto nemalou investici. Dostupnost informace o produktu musí být lehce dostupné na internetu při vyhledávání, je to myšleno při zadání obecných klíčových slov jako hotelové systémy. Reference hodnocení produktu za základě množství zákazníků, jejich známosti a prestiži Cena Jednorázová cena produkt je většinou k zakoupení po složení jednorázové částky, pro zákazníka je velmi směrodatné, zda tento údaj je k dispozici na stránkách nebo prezentaci programu. Pronájem u některých firem je možnost si software pouze pronajmout na určitou dobu a platit tak nižší částku, většinou měsíčně. Někdy to ale bývá i jediný způsob k zakoupení. Možnost úprav nabídka upravení základního systému na míru zákazníkovi podle jeho požadavků.

24 8 KAPITOLA 3. REŠERŠE EXISTUJÍCÍCH PRODUKTŮ Support do této kategorie spadají služby, které navíc k produktu nabízí prodejce. Jedná se například o telefonickou či ovou podporu, dále školení personálu pro obsluhu systému, některé firmy také nabízejí odborný dohled apod. 3.2 Popis vybraných systémů Nejprve dne proběhla analýza dostupnosti produktů na internetu. K tomuto účelu byl použit vyhledávač Google ( Zadáním klíčových výrazů hotelové systémy, hotelový software, ubytovací systémy byly nejčastějšími výsledky produkty: ABX recepce DeCe Hotel Fidelio Hores Hotel-Keeper Mefisto Previo Savarin smarthotel ABX recepce www stránky: Stejně jako řada podobných se tato firma nespecializuje pouze na hotelové systémy, ale také na pokladní software a k tomu nabízí dotykové pokladny a displeje. Co se týče samotného produktu Recepce R3 tak i když splňuje řadu funkcí, tak celý design působí dosti zastarale a nepřehledně. Více viz příloha B.1. DeCe Hotel www stránky: Hotelový software DeCe Hotel se skládá ze tří základních modulů: Recepce, Restaurace, Směnárna. Každý z nich je také možno zakoupit jako samostatný program. Bohužel, narozdíl od většiny ostatních zde porovnávaných DeCe Hotel nemá žádné speciální funkce,

25 3.2. POPIS VYBRANÝCH SYSTÉMŮ 9 nepodporuje žádné napojení na jiný software či jinou sít ovou komunikaci. Více viz příloha B.2. Micros Fidelio Suite 8 www stránky: Podle informací na stránkách se jedná o velký systém, který používají známé hotely. Prezentuje se jako v současnosti nejprodávanější recepční systém. Je možné, že z tohoto důvodu nepotřebuje výrobce na nich uvádět cenu a poskytovat demoverzi, vše řeší jinými způsoby a po poptávce zákazníka. Samotný produkt se jeví jako velmi propracovaný, možná ale až na úkor použitelnosti. Více viz příloha B.3. Hores www stránky: Komplexní systém obsahující celou řadu volitelných modulů a speciálních funkcí. Vyšší cena však bude při rozhodování zákazníka hrát podstatný faktor. Licenci základního programu pro 20 pokojů firma nabízí za ,- Kč. Ovšem s přídavnými moduly se cena lehce může vyšplhat až ke ,- Kč, což je pro malé a střední hotely podle mého názoru přespříliš vysoká investice. Více viz příloha B.4. Hotel-Keeper www stránky: Hotel-Keeper nabízí více různých verzí, jak pro velké hotely, pensiony, tak levnější odlehčenou verzi pro malé ubytovací zařízení. V nabídce také nalezneme vlastní systém pro restauraci. Značnou nevýhodou ale považuji, že restauraci nelze spojit nebo jinak integrovat s hlavním hotelových systémem, jedná se totiž o samostatnou aplikaci. Produkt od tohoto výrobce narozdíl od mnoha testovaných, ale poskytuje příjemné uživatelské rozhraní, které by nemělo být složité na ovládání. Více viz příloha B.5. Mefisto www stránky: Společnost Mefisto Software nabízí různé druhy systémů jak pro hotely, tak jen pro re-

26 10 KAPITOLA 3. REŠERŠE EXISTUJÍCÍCH PRODUKTŮ staurace, sportoviště, lázně, wellness centra. Hlavní prodávanou aplikací je Mefisto GRAND a pro menší hotely Mefisto Hotel. Jejich výhodou je, že celý systém je tvořen pomocí modulů, takže není problém integrace, například s nabízenou restaurací či skladovým hospodářstvím. Více viz příloha B.6. Previo www stránky: Jediná aplikace z hodnocených v této práci, která nelze zakoupit jednorázově. Je to z důvodu toho, že se jedná o webovou aplikaci a v případě zakoupení poběží na serveru společnosti Previo. Tato firma se dále specializuje na tvorbu www stránek a prezentací hotelů, které nabízí společně s hotelovým systémem. Za příplatek umožňuje zákazníkovi umístit na stránky tzv. online rezervaci pro hosty. Více viz příloha B.7. Savarin www stránky: Firma Savarin se spíše zabývá restauračními a pokladními systémy, prodává i speciální pokladní komponenty. Do této rešerše je zapojena díky modulu Recepce Savarin, který umožňuje funkce zde porovnávaných systémů, jako rezervovat pokoje a ubytovat tak hosty, vystavovat účty, kalkulovat prodej zboží a služeb a tak dále, více je rozepsáno opět v následující tabulce. Více viz příloha B.8. smarthotel (smartpension) www stránky: Poslední ze systémů je smarthotel, jehož odlehčená verze bez přídavných modulů je prodávána jako produkt smartpension. Pro potencionální zákazníky nepůsobí www stránky produktu příliš profesionálně především kvůli špatné optimalizaci pro rozdílné prohlížeče. Samotný systém však díky víceletému vývoji vypadá konkurenceschopně a bez chyb. Více viz příloha B.9.

27 3.3. SOUHRNNÁ TABULKA Souhrnná tabulka Porovnávané hotelové systémy: ABX Recepce DeCe Hotel Fidelio Hores Hotel-Keeper Mefisto Previo Savarin smarthotel Finance Provoz Recepce A A A A A A A A A Správa vybavení N N N N N N N N N Uživatelské účty A A A A A A A A A Správa personálu hotelu N N N N N N N N N Modul restaurace N A N N N A N A N Online rezervace A N A A N A A N A Další moduly A A A A N A A N A Speciální funkce A N A A A A N A A Pokladna A A A A A A A A A Tisk, export faktur A A A A A A A A Směnárna A A N A A A A A A Spolupráce s ubyt. servery N N N N A N A N N Přehledy, grafy A A A A A A A A A Tech. Webový systém N N A N N N A N N Propojení s jiným softwarem A N A A N A A N A Propojení poboček A N A A A A A N N Jednoduché ovládání, přehlednost N N N A A N N Cena Prop. Demoverze A A N A A N A A A Dostupnost A A A A A N A N N Jednorázová cena A A A A A N A A Pronájem N N N N A A A A N Možnost úpravy N N A A N A N N A Support A A A A A A A A A Tabulka 3.1: Souhrnná tabulka rešerše existujících produktů na trhu.

28 12 KAPITOLA 3. REŠERŠE EXISTUJÍCÍCH PRODUKTŮ 3.4 Vyhodnocení Rešerše potvrdila poměrně dostatečnou nabídku na našem trhu, navíc výčet produktů není rozhodně kompletní. Porovnávány byly pouze ty vybrané na základě výsledků internetového vyhledávače. Již na začátku byla v požadavcích stanovena správa objednávek a rezervací, proto nepřekvapí, že všechny hodnocené systémy obsahovaly modul rezervace. Co je zajímavé, tak ani jeden neposkytuje správu personálu hotelu a vybavení na jednotlivých pokojích. V ostatních kritériích se už ale většinou lišily. Modul restaurace obsahuje jen menšina aplikací, je to také z toho důvodu, že se převážně počítá s možností jeho samostatného nasazení do restaurace. Pokud se zaměříme na další moduly, tak každý systém bud to nějaké obsahoval nebo alespoň nabízel speciální funkce. Kalkulace a tok finančních prostředků je jednou ze základních funkcí podobných produktů, proto nechybí ani v jednom ze zmíněných, stejně tak tisk faktur a podobných dokumentů. Na druhou stranu nebylo příliš podporováno započítání provize do výsledné kalkulace při spolupráci s ubytovacími servery. Za povšimnutí stojí, že pouze dva systémy jsou webové, většina také při prvním setkání s uživatelem působí značně nepřehledně a složitě na ovládání. Co se týče propagace, tak firmy se snaží svůj produkt prodat, až na pár výjimek nabízejí k vyzkoušení své demoverze a jsou lehko dostupné při vyhledávání na internetu. Pro zákazníky nabízejí i jiné formy nákupu než jednorázové zaplacení, jako například na splátky nebo pronájem. Samozřejmostí je i určitá forma supportu. Z tabulky v předchozí kapitole, kde jsou přehledně zobrazena jednotlivá kritéria, nelze jednoznačně říci jaký program je nejlepší. Při výběru určitě hraje hlavní roli, pro jaké zařízení bude aplikace použita. Pro menší pensiony se bude hodit spíše levnější systém s méně funkcemi než pro velký pětihvězdičkový hotel. V naší analýze dva ze systémů není možné objektivně ohodnotit, protože společnosti nenabízejí jejich demoverze. Jiné zas působí dosti nepřehledně, složitě a nepřívětivě. Důležitým faktorem pro zákazníky musí také být moderní vzhled. Jako nejlepší pro ubytovací zařízení střední velikosti se jeví hotelový systém Previo, který sice neobsahuje různé speciální funkce (pay Tv, elektronické zámky na dveře, řízení teploty na pokojích), ale jehož výhodou je především webová forma, jednoduché ovládání a splnění většiny zkoumaných kritérií. Problém je pouze jeho nemalá cena a nemožnost jednorázového nákupu. Podle referencí ale vše nasvědčuje tomu, že v současné době hodně hotelů vsadilo na tuto variantu. Závěrem je tedy jednoduché odpovědět na otázku: Proč vyvíjet vlastní hotelový systém? Žádný totiž není tak dokonalý, aby měl všechny sledované funkce. Především správu vybavení a personálu defakto neměl implementován ani jeden. Převážná většina zkoušených aplikací na trhu není webová, což výrazně snižuje možnosti mobility. Navíc v budoucnu se podle mého názoru vše bude stěhovat na web, proto by bylo pro toto odvětví nevýhodné zůstat pouze v lokálních verzích. Prosadit se na českém trhu nebude i tak jednoduché, aby byl náš vlastní systém úspěšný, bude pro něj nutností obsažení funkcí, ve kterých se shodly a poskytovaly je všechny zde hodnocené produkty a dále přidání nových modulů, které ostatní nemají. V neposlední řadě je důležitá cenová relace a překonání tak často předražené konkurence.

29 Kapitola 4 Analýza V této části je nejprve provedena analýza současného stavu aplikace, zaměřená především na to, v čem předchozí systém pokulhával a zda se vůbec vyplatí na něj navazovat. Srovnání existujících produktů na trhu z předešlé kapitoly nám napomůže definovat a doplnit funkční a nefunkční požadavky, které jsou uvedeny dále. Jako součást analýzy nechybí ani ustanovení uživatelských rolí, odkaz na případy užití neboli USE-CASE diagramy a Konceptuální datový model, z něhož vychází návrh databáze a je jedním ze základních kamenů analýzy. 4.1 Původní aplikace V roce 2009 byla vytvořena bakalářská práce Realizace systému pro podporu hotelové agendy [11]. Systém byl navržen podle analýzy vypracované taktéž jako bakalářská práce Analýza informačního systému pro ubytovací zařízení [14] studentem Petrem Vůjtěchem. Samotný návrh byl obsáhlý a výsledný program by tak přesahoval rámce bakalářské práce, proto byla zpracována jen část funkcionality, což bylo plně dostačující. I tak měla aplikace řadu nedostatků a dnes s odstupem doby bych řadu věcí po nabytých zkušenostech implementoval jinak. Největším problémem bylo nedostatečné rozdělení persistentní vrstvy a logiky aplikace, tedy vrstvy, kde se mimo jiné nacházejí controllery. Jako základ byl použit návrhový vzor Model-View-Controller 1. Jako datová vrstva byl implementován pouze čistý model aplikace a vše ostatní kromě view bylo uloženo v třídách Controlleru, které například zpracovávaly uživatelský vstup a také přímo prováděly dotazy do databáze, což rozhodně není dobrý způsob. Značně je omezena možnost budoucího rozšiřování, či výměny jednotlivých částí jako datového úložiště, uživatelského rozhraní. Dnes se tento problém řeší například návrhovým vzorem DAO 2 nebo technologií EJB 3 (viz stejnojmenná kapitola 5.1.3). Za nedostatek také považuji nepříliš vhodně zvolený způsob validace a chyby vycházející z neefektivní práce s datovým modelem a databází. Při tvorbě také vzniklo poměrně značné množství redundantního kódu. 1 Model-View-Controller návrhový vzor, který rozděluje aplikaci na datový model, řídící logiku a uživatelské rozhraní. 2 DAO (Data Access Object) objekt, který poskytuje rozhraní pro přístup do databáze. 3 Enterprise Java Beans serverová komponentová architektura, která je součástí platformy Java EE. 13

30 14 KAPITOLA 4. ANALÝZA Vše zde zmíněné vyplývá z toho, že na bakalářské práci jsem se hlavně učil pro mě novým technologiím a protože s tvorbou enterprise 4 systémů jsem do té doby neměl téměř žádné zkušenosti, vznikli tyto nedokonalosti. Vzhledem k výše zmíněným záležitostem jsem se rozhodl začít implementaci systému úplně od začátku pouze s využitím analýzy a návrhu z původní předlohy. Tyto části, i když byli zpracovány kvalitním způsobem, bude stejně záhodno více rozpracovat a vylepšit. 4.2 Funkční a nefunkční požadavky Základní funkční a nefunkční požadavky zůstávají stejné jako pro bakalářskou práci. Došlo k přidání několika dalších a jejich počet se tak rozrostl. Zde je uveden celkový seznam: Funkční požadavky: Systém bude umožňovat spravování objednávek (zastřešuje rezervaci pokojů, požadavky na stravování, prodej služeb, zboží). Systém bude uchovávat informace o zákaznících ubytovacího zařízení. Systém bude podporovat spolupráci s partnery. Systém bude poskytovat přehledy a statistické údaje. Systém bude evidovat turistické a ubytovací poplatky, které je ubytovací zařízení ze zákona povinno odvádět. Systém bude evidovat informace o pokojích. Systém bude evidovat informace o sezónách. Systém bude evidovat informace o cenách pokojů vzhledem k obsazenosti pokoje a sezóně. Systém bude přístupným pouze registrovaným uživatelům. Systém bude spravovat vybavení na pokojích Systém bude zákazníkům umožňovat přes webové stránky hotelu online rezervaci. Systém bude poskytovat jednoduchou správu zaměstnanců. Systém bude zobrazovat přepočty celkových cen podle aktuálních kurzů. Systém bude umožňovat tisk(export) faktur pro jednotlivé objednávky a tisk(export) knihy hostů. 4 Enterprise systém typicky se jedná o rozsáhlý podnikový systém umožňující správu různých procesů

31 4.3. DEFINICE UŽIVATELSKÝCH ROLÍ 15 Nefunkční požadavky: Systém bude přístupný přes webové rozhraní. Systém bude implementován v multiplatformním programovacím jazyce. Systém bude mít jednoduché a přehledné uživatelské rozhraní a ovládání. Data budou uložena v relační databázi. Stránky budou ve validním HTML a CSS. Systém bude správně zobrazován v hlavních webových prohlížečích. 4.3 Definice uživatelských rolí Do systému budou přistupovat různí uživatelé, od recepčních až po administrátory. Proto bude nutné tyto aktéry rozdělit do skupin s různými pravomocemi. Obrázek 4.1: Uživatelské role. Podle diagramu je zřejmé, že je počítáno se třemi základními rolemi: Recepční jedná se sice o nejnižší roli v systému, ale jediné s čím nebude moci pracovat bude správa zaměstnanců a dalších uživatelů. Všechny ostatní možnosti budou všem recepčním zpřístupněny. Manažer tato role představuje například vedoucího směny. Narozdíl od recepční může spravovat zaměstnance a v případě pokojské nebo údržbáře přiřazovat úklidy, resp. opravy. Administrátor role administrátora je klasicky vyhrazena uživatelům s nejvyššími právy a bez žádného omezení. V aplikaci bude mít navíc možnost vytvářet a editovat manažery, ale i další administrátory za předpokladu, že jich bude potřeba více než jeden.

32 16 KAPITOLA 4. ANALÝZA 4.4 Případy užití Jednotlivé případy užití vycházejí z požadavků na aplikaci, pokud většina z nich byla zachována, jak se píše v kapitole 4.2, nedochází ani u USE-CASE diagramů k převratným změnám a při tvorbě této práce byly využity původní z bakalářské práce [14]. 4.5 Konceptuální datový model Konceptuální datový model doznal oproti původní verzi [14] částečných změn. Zaprvé bylo nutné opravit chyby. Třída Ceník byla omezena pouze pro kapacitu osmi hostů. Sice se nepředpokládá, že by hotel potřeboval umístit tolik hostů na jeden pokoj, ale i tak tento nedostatek značně omezoval flexibilitu datového modelu a byl nevhodně navržen. Řešením je vytvoření dvou atributů v Ceníku a určení tak ceny pro jakoukoliv obsazenost. Další problém spočíval v nemožnosti přidávat více stejných zboží či služeb k objednávce. Namísto vztahu N:M byla přidána třída nahrazující tento vztah a atribut určující počet. Vzhledem k rozšíření funkčních požadavků bylo nutné systém k jejich splnění i dostatečně rozšířit. Ke každému pokoji se nově váže třída Vybavení umožňující správu nábytku a dalšího zařízení. Díky nepovinnosti vazby je možné evidovat i vyřazené věci nebo jen uschované ve skladu. Samostatným oddílem je správa zaměstnanců. K modelu jsou připojeny entity typu Zaměstnanec, Manažer, Recepční, Pokojská, Údržbář a společně s původní třídou Uživatele vytvářejí jednoduchý strom dědičnosti. Podle jednotlivých tříd jsou také všichni uživatelé aplikace klasifikováni do uživatelských rolí. Zaznamenávány jsou rovněž činnosti pokojských a údržbářů ve formě úklidů a oprav provedených vždy v určitý den. Pro online rezervace se přidala nová samostatná entita Předběžné rezervace. Důvod, proč tyto údaje nejsou nijak zakomponovány do hlavní části s objednávkou, je prostý. Návštěvník webu může formulář vyplnit nesmyslnými údaji a proto je nutná následná kontrola uživatele systému. Pro tvorbu všech UML 5 diagramů uvedených v této diplomové práci byl použit nástroj Enterprise Architect 7.5 [12]. 5 UML (Unified Modeling Language) je grafický jazyk pro návrh a dokumentaci softwarových systémů.

33 4.5. KONCEPTUÁLNÍ DATOVÝ MODEL 17 Obrázek 4.2: Konceptuální datový model.

34 18 KAPITOLA 4. ANALÝZA

35 Kapitola 5 Návrh řešení Návrh řešení se snaží blíže přiblížit konkrétní implementaci a systém navrhnout již v závislosti na zvolené platformě a implementačním prostředí. Kapitola začíná popisem technologií použitých při vývoji systému a nastínění způsobu práce s nimi. V další části jsou uvedeny diagramy komponent a nasazení. 5.1 Výběr implementačního prostředí Java Enterprise Edition Pro vytvoření systému je využita platforma Java Enterprise Edition [4], která se přímo hodí k vývoji velkých podnikových aplikací a informačních systémů. Je založena na vícevrstvé architektuře, jenž rozděluje aplikaci na prezentační, aplikační a persistentní vrstvu. Specifikace, které spadají pod Java EE, i zmíněné vrstvy jsou blíže rozebrány v následujícím textu Java Server Faces Java Server Faces [4] (dále jen JSF) je komponentově orientovaný framework pro webové aplikace. Znamená to, že celá webová stránka je složena z jednotlivých komponent, které jsou v systému chápány jako interaktivní složka. Pod pojmem komponenta si například můžeme představit formulář, odkaz, tlačítko nebo jen vstupní pole ve formuláři. Jejich výhodou je, že se dají vzájemně skládat a vytvářejí tak další. Většina komponent jsou vyšší logické celky, vzniklé složením z několika tříd: Tag reprezentuje komponentu, tak jak ji zapisujeme do webové stránky (například input- Text, selectonelistbox, OneListbox). Zpracuje požadavek od uživatele a předá dále logice. UI Component tato třída zastává aplikační logiku celé komponenty, jako třeba konverzi hodnot na text, volání action metod nebo validace (jedná se např. o třídy UIInput, UISelectOne). 19

36 20 KAPITOLA 5. NÁVRH ŘEŠENÍ Renderer je poslední třídou, ze které se taková typická komponenta skládá. Má za úkol převést komponentu do html kódu, stará se tedy o vykreslování. Při vykreslování stránky je vždy vytvořen tzv. komponentový strom. Na obrázku 5.1 můžeme vidět příklad stromu složeného z kořene UIView obsahující komponentu OutputText a formuláře s jedním vstupním polem a tlačítkem. Obrázek 5.1: Strom komponent v JSF (zdroj [13]). Uživatel odešle požadavek na server například kliknutím na tlačítko. Daná komponenta (v našem případě commandbutton) vyvolá event a ten je zpracován hlavním Servletem v JSF. Jedná se o tzv. FacesServlet, který zpracovává eventy vyvolané jednotlivými komponentami a jiné uživatelovy požadavky. Stará se defakto o propojení HTML 1 a Javy. V případě, že do něj přistoupí více požadavků, zpracuje je vícevláknovým způsobem, každý jako jedno vlákno. Framework Java Server Faces, obdobně jako další podobné, se drží architektury MVC. Díky tomu efektivně odděluje prezentační vrstvu od zbytku aplikace. V následujících odstavcích si představíme další sounáležitosti s tímto frameworkem spojené Managed Beans Managed Beans také často označovány jako Backing Beans, jsou jedním ze základních kamenů v Java Server Faces, protože zajišt ují aplikační logiku systému. Jedná se v podstatě o Java třídy, obsahující gettery, settery a metody, reagující na události komponent. 1 HTML (HyperText Markup Language) značkovací jazyk určený především pro vývoj webových stránek.

37 5.1. VÝBĚR IMPLEMENTAČNÍHO PROSTŘEDÍ public class MyBean{ 4 5 private String name; 6 7 public String getname(){ 8 return name; 9 } public void setname(string name){ 12 this.name = name; 13 } } Dříve se definovalo použití určité Managed Beany v konfiguračním xml souboru faces-config.xml, dnes ve specifikaci JSF 2.0 [5] toto můžeme nahradit pomocí anotací přímo nad deklarací určité třídy, což je při programování o mnoho pohodlnější. Důležitým parametrem u Managed Beans je scope, který určuje životnost Beany. Request nastavení request znamená, že Beana se vytvoří při požadavku uživatele a po jeho vyřízení je odstraněna. Session jak už název napovídá, životnost takové Beany je pouze v rámci jedné session. Aplication při této volbě parametru, je aktivní po celou dobu co běží aplikace na serveru. None když nastavíme scope na none, tak Beana není nijak ukládaná, ani viditelná pro JSF stránku, vytváří se až na vyžádání. Většinou se tato volba používá, když jedna Beana referencuje na jinou, které se přiřadí scope typu none Navigace Načtení dat z formuláře do nějaké Beany a umožnit tak programátorovi další práci s těmito daty umí celá řada frameworků. Java Server Faces umí ještě něco navíc a jedna z těchto věcí je například navigace. Pod tímto pojmem se rozumí přechod ze stránky na jinou stránku, vyvolaný třeba stisknutím tlačítka. Statická navigace Rozlišujeme dva druhy navigace, první z nich je tzv. statická navigace, kde je napevno zadán atribut action. Nejprve je ale zapotřebí nastavit pomocí navigačních pravidel <navigationrule> do konfiguračního souboru faces-config.xml, co se má za dané situace dělat. Zde na ukázce je příklad takového pravidla, kde v případě, že se nacházíme na stránce first.xhtml a dojde k vyvolání akce next, tak dojde k přechodu na stránku second.xhtml. <h:commandbutton... action="next"/>

38 22 KAPITOLA 5. NÁVRH ŘEŠENÍ Obrázek 5.2: Statická navigace v JSF. 1 <faces-config> <navigation-rule> 4 <from-view-id>/first.xhtml</from-view-id> 5 <navigation-case> 6 <from-outcome>next</from-outcome> 7 <to-view-id>/second.xhtml</to-view-id> 8 </navigation-case> 9 </navigation-rule> </faces-config> Dynamická navigace Druhým typem je dynamická navigace znázorněná na následujícím příkladu. Metoda ve třídě MyBean může vracet nějaké řetězce, podle toho co vrátí, tak to se pak použije jako směrování na další stránku. Navíc když method() vrátí řetězec o stejném názvu jako je stránka, tak se jedná o implicitní navigaci. Systém sám určí přechod na novou stránku a programátor nemusí zapisovat žádná navigační pravidla do konfiguračního souboru faces-config.xml. <h:commandbutton... action="#{user.method}"/> Obrázek 5.3: Dynamická navigace v JSF. 1 public class MyBean { public String method() { 4 if (...) {

39 5.1. VÝBĚR IMPLEMENTAČNÍHO PROSTŘEDÍ 23 5 return "index"; 6 } 7 return "next"; 8 } 9 } Konverze Další co JSF umí je konverze, neboli konvertování vstupních hodnot. Využijeme ji, pokud budeme chtít hodnotu (řetězec) co uživatel zapsal do vstupního pole ve formuláři zkonvertovat do nějakého javovského objektu. Konverze na čísla probíhá automaticky, takže tím se nemusíme zatěžovat. Konverzi je vhodné použít pro datum nebo čas, jako je zde na ukázce, využitím konvertoru, který poskytuje JSF, konkrétně pro rok. 1 <h:inputtext value="#{dotaznik.year}"> 2 <f:convertdatetime pattern="yyyy"/> 3 </h:inputtext> Také si můžeme vytvářet vlastní konvertory. Základem je třída implementující interface Convertor se dvěmi metodami getasobject(), která vrací objekt a metoda getasstring(), která vrací řetězec pro zpětné zobrazení objektu na stránce. Tyto metody tedy slouží k převádění řetězce na náš požadovaný objekt a zas naopak. Přidání konvertoru do našeho systému se provede v faces-config.xml. Nově ve verzi JSF 2.0 můžeme využít anotací a konvertor tak zaregistrovat do systému tímto způsobem. 2 class PhoneConverter implements Converter { 3 public Object getasobject() {...} 4 public String getasstring() {...} 5 } Validace Dále Java Server Faces obsahuje také podporu pro validaci. Funguje klasickým způsobem, když uživatel odešle data pomocí formuláře, tak než se začnou dále zpracovávat systémem, provede se validace, která ověří, zda byla například vyplněna všechna povinná políčka nebo zda jsou vyplněna správně. Defaultních validátorů je poměrně málo, takže pokud budeme programovat vlastní JSF aplikaci, tak dozajista využijeme možnost tvorby vlastních validátorů. Jejich implementace je velice podobná jako u konvertorů. Třída našeho validátoru implementuje interface Validator, kde hlavní metodou, která se při validaci volá, je validate(). Pokud data neprojdou validací je vyhozena výjimka a další zpracování dat je zastaveno, nedojde k uložení dat do beany a ukončí se uživatelova žádost. Důležitou vlastností je, že když se validuje formulář a třeba

40 24 KAPITOLA 5. NÁVRH ŘEŠENÍ jen jedno pole na začátku neprojde, tak se ještě zkontrolují i další. Důvod je prostý, uživatel díky tomu uvidí všechny chyby, co ve formuláři udělal. Na následujícím kódu můžeme vidět, jak by se takový validátor implementoval. V prvním případě pomocí faces-config.xml, ve druhém jednodušeji, pomocí 2 public class Validator implements Validator{ 3 public void validate(facescontext fc, UIComponent comp, 4 Object value) throws ValidatorException { } 7 } Životní cyklus Java Server Faces Chod aplikace a zpracování žádostí je řízeno podle životního cyklu JSF. Má šest hlavních fází, mezi nimiž jsou různé mezistavy pro zpracování událostí. Na začátku přijde request od uživatele a poté už následuje první fáze: 1. Restore View při této fázi dojde k postavení komponentového stromu (viz obr. 5.1). 2. Apply Request Values přečtou se parametry, které nese žádost. Například když dojde k vyplnění a odeslání nějakého formuláře, načtou se vyplněná data. 3. Validation třetí fází je validace načtených dat. 4. Update Model Values zde dojde k uložení nových hodnot z formuláře do Managed Beany, kde s nimi pak programátor může dále pracovat. 5. Invoke Application neboli fáze akce a navigace. Proběhnou metody navázané na komponentu a v případě implementovaného přesměrování, dojde k přechodu na jinou stránku. 6. Render Response je poslední fází předtím, než se odešle zpět uživateli odpověd. Na serveru se zavolá initial request na novou stránku a také se v tomto stádiu mohou uložit stavy komponent, pokud je potřeba. V případě, že došlo k prvnímu načtení stránky a session je prozatím prázdná, přechází se z první fáze ihned na vytvoření odpovědi JSF 2.0 V roce 2009 byla vydána platforma Java EE 6 [5] jejíž součástí je nová verze JSF 2.0, která přinesla řadu inovací. Zde je výčet těch nejhlavnějších: není potřeba psát všechny konfigurační informace a metadata do souboru faces-config.xml, ale je možné využít jednodušších a přehlednějších anotací,

41 5.1. VÝBĚR IMPLEMENTAČNÍHO PROSTŘEDÍ 25 součástí Java Server Faces je také šablonovací systém Facelets založený na standardu XML 2, vylepšená integrace Ajaxu, zjednodušení tvorby vlastních komponent, podpora GET requestu, pomocí něhož můžeme také efektivně přenášet data, implicitní navigace, vylepšení výjimek a validace, nové druhy scope pro Managed Beans View, Custom, nové komponentové knihovny, a další Enterprise Java Beans (EJB) Dostatečné oddělení persistentní a aplikační vrstvy zajistí technologie Enterprise Java Beans [4], součást platformy Java EE. Třídy zajišt ující v našem systému tuto funkcionalitu se nazývají Session Beany, které jsou jedním z dvou typů Enterprise Java Beans (druhé Message Driven Beans zde nejsou popisovány). Jak je vidět na obrázku 5.4, EJB implementuje tzv. servisní (business) vrstvu aplikace. Pracuje s datovou vrstvou a její EJB metody jsou volány aplikační vrstvou, kterou reprezentují Managed Beany. Programátor se o mnoho věcí při používaní EJB nemusí zajímat. O inicializaci se postará kontejner, stejně tak o přístup k Entity Manageru, vše pomocí dependency injection. 2 public class HotelSessionBean implements HotelSessionBeanLocal{ 3 5 private EntityManager em; 6 7 public Guest getguest(integer id){ 8 Guest guest = em.find(guest.class, id); 9 return guest; 10 } } 2 XML (Extensible Markup Language) [19] obecný značkovací jazyk, který je především určen pro výměnu dat mezi aplikacemi a pro publikování dokumentů ve standardizovaném formátu.