On-line rezervační systém

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

On-line rezervační systém Radek Menšík

Vedoucí práce: Ing. Zdeněk Míkovec Studijní program: Výpočetní technika květen 2007

Poděkování Za vedení diplomové práce a cenné rady děkuji Ing. Zdeňkovi Míkovci. Dále bych rád poděkoval svým rodičům a přátelům za podporu.

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady (literaturu, projekty, SW, atd.) uvedené v přiloženém seznamu. Nemám závažný důvod proti použ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 24. 5. 2007 Radek Menšík

Abstract This thesis deals with a design and implementation of the On-line reservation system for a hairdressing parlour. The aim is to design and implement an application, which will make reservations more clear and at the same time will enable a customer to make a reservation for a visit without a necessity of communication with parlour´s crew. This work uses advantages of the Jakarta Struts framework and in some parts the user interaction efficiency is increased by usage of Ajax technology .The emphasis is put mainly on simplicity of the reservation itself and also maintenance of the whole application including the operations necessary for administration of all visits. The reservation and administration processes as very complex tasks were optimized by means of design of efficient algorithms, minimization of computation time and user friendliness.

Abstrakt Tato diplomová práce se zabývá návrhem a realizací On-line rezervačního systému pro kadeřnický salón. Cílem je navržení a vytvoření aplikace, která zpřehlední veškeré rezervace a zároveň umožní rezervaci návštěvy zákazníkem bez nutnosti komunikace s obsluhou salónu.Práce využívá výhody rámce Jakarta Struts a na několika místech ji zpřehledňuje technologie Ajax.Důraz je kladen především na jednoduchost samotné rezervace i údržbu celkové aplikace včetně operací nutných ke spravování všech návštěv. Operace spojené s rezervací a správou návštěv jakožto velmi komplexní úlohy, byly optimalizovány co se týče algoritmů, rychlosti výpočtů a uživatelské přívětivosti.

Obsah

Obsah I Seznam obrázků........................................................................................................ XI II Seznam tabulek.......................................................................................................XII 1 Úvod.............................................................................................................................. 1 1.1 Motivace................................................................................................................... 1 1.2 Členění diplomové práce.......................................................................................... 2 2 Úvodní studie............................................................................................................... 3 2.1 Současné fungování kadeřnického salónu................................................................ 3 2.2 Scénáře chování uživatelů........................................................................................ 4 2.3 Texty úvodní studie.................................................................................................. 5 2.3.1 Deklarace záměru.............................................................................................. 5 2.3.2 Odborný článek................................................................................................. 5 2.4 Hlavní rysy aplikace................................................................................................. 7 2.5 Diagram kontextu..................................................................................................... 8 2.6 Případy užití..............................................................................................................9 2.6.1 Případ užití pro aktéra Uživatel....................................................................... 10 2.6.2 Případ užití pro aktéra Zaměstnanec............................................................... 10 2.6.3 Případ použití pro aktéra Správce....................................................................11 2.7 Stanovení dosažitelných cílů pro tuto diplomovou práci....................................... 11 2.7.1 Plán nutných úprav.......................................................................................... 12 3 Analýza....................................................................................................................... 14 3.1 Současné řešení...................................................................................................... 14 3.2 Katalog požadavků................................................................................................. 14 3.2.1 Požadavky na software.................................................................................... 14 3.2.2 Požadavky na hardware................................................................................... 15 3.3 Požadavky na vytvářený software.......................................................................... 15 3.3.1 Informace udržované v databázi...................................................................... 16 3.3.2 Správa dat........................................................................................................ 17 3.3.3 Automatické rozesílání emailů........................................................................ 18 3.3.4 Automatický výpočet vytíženosti.................................................................... 18 3.3.5 Pomocné návrhy.............................................................................................. 18 3.3.6 Graf vytíženosti............................................................................................... 18 3.3.7 Podpora více jazyků........................................................................................ 18 3.4 Datová analýza...................................................................................................... 19 3.4.1 ER diagram...................................................................................................... 19 3.4.2 Popis reprezentace dat..................................................................................... 19 3.4.3 Hodnoty dat a relace........................................................................................ 21 3.5 Modelování procesů pomocí diagramů aktivit....................................................... 23 3.5.1 Rezervace návštěvy klientem.......................................................................... 23 3.5.2 Úprava návštěvy.............................................................................................. 25 3.5.3 Diagram přeobjednání návštěvy (operátorem)................................................ 25 3.5.4 Nastavení nepřítomnosti personálu................................................................. 26 3.6 Stručný úvod do požadovaných technologií...........................................................27 On-line rezervační systém VIII

Obsah

3.6.1 Jakarta Struts................................................................................................... 27 Technologie JSP...................................................................................................... 27 Model-View-Controller ve Struts............................................................................ 28 3.6.2 Technologie AJAX.......................................................................................... 29 3.7 Závěrem k analýze.................................................................................................. 31 4 Návrh.......................................................................................................................... 32 4.1 Popis základního návrhu jednotlivých komponent.................................................33 4.1.1 ActionPackage................................................................................................. 34 4.2 Návrh mapy stránek................................................................................................ 36 4.3 Návrh uživatelského rozhraní................................................................................. 38 4.3.1 Vzhled..............................................................................................................38 4.3.2 Šablony............................................................................................................ 39 4.3.3 Podpora více jazyků........................................................................................ 40 4.3.4 Důležité detaily uživatelského rozhraní.......................................................... 40 4.4 Akceptační testy a testy použitelnosti.................................................................... 41 4.4.1 Testy použitelnosti...........................................................................................41 5 Implementace............................................................................................................. 42 5.1 Použité technologie a nástroje................................................................................ 42 5.1.1 Volba technologií............................................................................................ 42 5.1.2 Volba nástrojů................................................................................................. 42 5.1.3 Jakarta Struts podrobněji................................................................................. 43 5.2 Stručný přehled použitých nestandardních knihoven............................................. 46 5.2.1 Knihovny Javy................................................................................................. 46 5.2.2 Knihovny Struts............................................................................................... 46 5.3 Popis některých částí implementace....................................................................... 47 5.3.1 Rezervace........................................................................................................ 47 5.3.2 Statická knihovna MyDate.............................................................................. 50 5.3.3 Statistiky.......................................................................................................... 50 5.3.4 Generování tabulky kalendáře......................................................................... 50 5.3.5 Ajax ve formuláři Event.................................................................................. 52 5.3.6 Server rutines................................................................................................... 55 5.3.7 Centralizace kontroly přístupových práv.........................................................56 5.3.8 Validace........................................................................................................... 56 5.3.9 Tabulkový výpis.............................................................................................. 57 5.4 Chyby v použitých knihovnách.............................................................................. 58 5.4.1 Diakritická znaménka...................................................................................... 58 5.4.2 Názvy formulářů.............................................................................................. 58 5.4.3 Validace........................................................................................................... 58 5.4.4 Nové verze Struts ........................................................................................... 59 5.4.5 Generovaný HTML kód knihovou Struts Layout........................................... 59 5.5 Možná vylepšení algoritmů.................................................................................... 59 5.5.1 Algoritmus vyhledávání volna pro rezervaci.................................................. 59 5.5.2 Nákupní košík.................................................................................................. 60 5.5.3 Vzájemné vyloučení služeb............................................................................. 60 6 Testování.................................................................................................................... 61 On-line rezervační systém IX

Obsah

6.1 Jednotkové testy..................................................................................................... 61 6.2 Integrační testy....................................................................................................... 61 6.3 Testy uživatelského rozhraní.................................................................................. 61 6.4 Validační a systémové testy, akceptace a testy použitelnosti.................................62 6.4.1 Testy použitelnosti...........................................................................................62 6.4.2 Systémové testy............................................................................................... 65 6.4.3 Plán testů......................................................................................................... 65 7 Závěry......................................................................................................................... 66 8 Seznam literatury...................................................................................................... 69 8.1 Seznam literatury.................................................................................................... 69 8.2 Internetové odkazy................................................................................................. 69 Formulář akceptačního testu......................................................................................71 Formulář akceptačního testu......................................................................................71 A Ostatní tabulky databáze......................................................................................... 72 A Ostatní tabulky databáze......................................................................................... 72 B Ukázky obrazovek aplikace..................................................................................... 75 B Ukázky obrazovek aplikace..................................................................................... 75 C Obsah přiloženého CD............................................................................................. 81 C Obsah přiloženého CD............................................................................................. 81 D Instalační příručka................................................................................................... 82 D Instalační příručka................................................................................................... 82

On-line rezervační systém X

Seznam obrázků

I Seznam obrázků Obr. 1 – Diagram kontextu..............................................................................................8 Obr. 2 – Případ užití nejvyšší úrovně............................................................................. 9 Obr. 3 – Diagram případu užití uživatele.................................................................... 10 Obr. 4 – Diagram případu užití zaměstnance..............................................................11 Obr. 5 – Diagram případu použití správce aplikace.................................................. 12 Obr. 6 - ER diagram.......................................................................................................20 Obr. 7 - Diagram aktivity – Rezervace návštěvy klientem......................................... 24 Obr. 8 - Diagram aktivity – Upravit event................................................................... 25 Obr. 9 - Diagram aktivity – Přeobjednání návštěvy................................................... 26 Obr. 10 - Diagram aktivity – Nastavení nepřítomnosti personálu.............................27 Obr. 11 – Model-View-Controller (View zde dolní část obdélníku), převzato z 8.2.29 Obr. 12- Schéma fungování technologie Ajax, převzato z ......................................... 31 Obr. 13 – Vazby mezi navrženými balíky.................................................................... 32 Obr. 14 –Balík utils........................................................................................................ 33 Obr. 15 –Návrh tříd MySQL a Mail.............................................................................34 Obr. 16 – Balíky vnořené do ActionPackage .............................................................. 34 Obr. 17 –Návrh tříd PersonalBusy a EventAction...................................................... 35 Obr. 18 – Mapa stránek uživatele................................................................................. 36 Obr. 19 – Mapa vybraných stránek pro personál....................................................... 37 Obr. 20 – Návrh vzhledu stránky..................................................................................38 Obr. 21 – Návrh speciálních stránek............................................................................ 39 Obr. 22 –Návrh kalendáře............................................................................................. 39 Obr. 23 –Nabídka časů v zaplněném dnu.....................................................................53 Obr. 24 –Výsledek použití Struts-Layout.....................................................................57 Obr. 25 - Úvodní obrazovka procesu rezervace.......................................................... 75 Obr. 26 - Historie návštěv.............................................................................................. 76 Obr. 27 - Pohled administrátora na dovolenou........................................................... 77 Obr. 28 - Pohled na vytíženost personálu.....................................................................78 Obr. 29 - Chyby jsou zachytávány již na klientské straně......................................... 79 Obr. 30 - Výsledek špatně zadaných vstupů ............................................................... 79 Obr. 31 - Pohled do diáře...............................................................................................80

Online rezervační systém XI

Seznam tabulek

II Seznam tabulek Tab. 1 - Entita service.................................................................................................... 19 Tab. 2 – Hodnoty a názvy rolí....................................................................................... 21 Tab. 3 - Entita user.........................................................................................................22 Tab. 4 - Entita event....................................................................................................... 22 Tab. 5 - Entita closed......................................................................................................23 Tab. 6 – Ukázka úpravy nabízených časů.................................................................... 49 Tab. 7 - Účastníci testu použitelnosti............................................................................ 63 Tab. 8 - Entita log (* Entita zatím není využívána a lze očekávat její rozšíření)..... 72 Tab. 9 - Entita openhours.............................................................................................. 72 Tab. 10 - Entita prefer_days..........................................................................................72 Tab. 11 - Entita personal............................................................................................... 72 Tab. 12 - Entita prefer_partday.................................................................................... 73 Tab. 13 - Entita personalfreetime................................................................................. 73 Tab. 14 - Entita prefer_personal...................................................................................73 Tab. 15 - Entita role........................................................................................................73 Tab. 16 - Entita role_def................................................................................................ 73 Tab. 17 - Entita statistichistory..................................................................................... 73 Tab. 18 - Entita statisticpersonal.................................................................................. 74

On-line rezervační systém XII

Úvod

1 Úvod Dostupnost připojení k Internetu je v současnosti standardem většiny domácností a jeho využití již není omezeno na vybrané obory a osoby. Mnozí uživatelé pochopili, že Internet a online svět vůbec neslouží jen k získávání a sdílení statických informací. Mezi největší výhody šetřící nejen čas, ale i peníze patří tzv. on-line rezervace předmětů a služeb. Protože sám často využívám této internetové možnosti, chtěl bych rozšířit stávající nabídku systémů o systém další, v mnohém výjimečný . Rád jsem proto přistoupil na nabídku návrhu a realizace on-line systému pro kadeřnický salón.

1.1 Motivace Osobní styk a telefonní komunikace s osobou či firmou je v současné době nahrazován neosobní „automatickou“ komunikací s klientem. Jedná se především o obory, kdy uživatelé (zákazníci) hledají odpovědi na velmi podobné otázky nebo mají obecně definovatelné konkrétní požadavky. Mezi nejstarší strojovou komunikaci můžeme zařadit telekomunikaci s automatem, který nabízí témata a uživatel téměř současně pomocí číslic telefonu volí nejvhodnější nabídku. Tímto způsobem dokážeme rozdělit požadavky zákazníka a přepojit jej ke konkrétnímu pracovníkovi, který pak nemusí pokládat základní otázky (již byly zodpovězeny). Vylepšením posledních let je automatické rozeznávání mluvených odpovědí a tím nahrazení volby pomocí tlačítek telefonu. Mnozí lidé nechtějí telefonovat, a to z několika důvodů: často má druhá strana obsazeno; telefonující nechce, aby okolí slyšelo, co si objednává, nerad komunikuje s osobou, kterou nevidí, nebo se během hovoru nedokáže rychle rozhodnout pro jednu z nabízených variant. Častý je i psychologický tlak druhé osoby, který může být nepříjemný. Úplného vyřazení živé osoby z komunikace lze využít při zadávání požadavků na předměty a objekty či konkrétní služby. Výhoda elektronického zjištění, možnosti využití leteckého spoje a on-line zadání požadavku na rezervaci letenky je patrná na první pohled. Např. při navštívení portálu letecké společnosti si můžeme v klidu rozmyslet termín letu, seznámit se s nabídkami konkurenčních společností, zhodnotit, která nabízená trasa je nejvýhodnější, zjistit různé poplatky apod. To vše provedeme, aniž bychom se rozptylovali či byli pod tlakem okolí. Podíváme-li se na systém z pohledu jeho tvůrce, vyplyne jasně, proč není nutné do celého procesu zapojovat člověka. Při volbě konkrétního požadavku, který je definován termínem, volbou objektu a množstvím (přičemž množství je omezeno), nám termín ze všech objektů vytvoří objekty unikátní a sám objekt není závislý na žádných nepředpokládatelných událostech - nepotřebujeme žádné „lidské“ rozhodnutí. V případě letu je objekt definovaný počtem míst v dané kategorii a číslem letu (světově unikátním). On-line rezervační systém 1

Úvod

V současné době je tedy stále běžnější setkání s elektronickými rezervačními systémy, které nahrazují rutinní činnost člověka. Toho by měl dosáhnout i systém navržený a implementovaný v této práci. Chcete umýt hlavu a ostříhat vlasy? Tak to nám zabere jednu hodinu. Kdy můžete přijít? V pondělí odpoledne? Ano, máme tu místo od čtyř hodin, souhlasí? Výborně, znamenám si Vás a těšíme se na shledanou, paní Zákaznice! Takovéto stále stejně znějící rozhovory mohou být ze značné části nahrazeny zvuky klávesnice a myši.

1.2 Členění diplomové práce Diplomová práce je rozdělena do několika částí. V kapitole Úvodní studie je popsáno současné fungování salónu, pro který je aplikace vyvíjena. Rozebrány jsou případy použití. V kapitole Analýza jsou definovány požadavky na systém, rozebrán návrh databáze a několik procesů je zobrazeno pomocí diagramů aktivit. V závěru kapitoly je nastíněn úvod do použitých technologií. Čtvrtá kapitola se věnuje návrhu jednotlivých komponent, grafických šablon a komplikovanějších tříd. Najdeme zde také plán mapy stránek. V kapitole Implementace se seznámíme s použitými technologiemi a technikami. Jsou zde rozebrány některé implementační postupy a chyby v použitých knihovnách, které ovlivnily vývoj programu. Další krátká kapitola popisuje testování aplikace. Poslední odstavce jsou věnovány rozboru a hodnocení práce.

On-line rezervační systém 2

Úvodní studie

2 Úvodní studie Snahou této práce je vytvořit elektronický rezervační systém pro množinu provázaných kadeřnických a kosmetických úkonů kadeřnického salónu. Jednotlivé úkony mohou být prováděny pouze omezeným množstvím zdrojů, některé z nich lze provádět zároveň. Hlavním omezením oproti výše zmíněnému systému je, že si zákazník nemůže zvolit konkrétní termín, resp. nevidí vytížení zdrojů (jeden z požadavků). Jinak řečeno se jedná o různě dlouhé rezervování zdrojů, přičemž požadovaných zdrojů může být více. Aby bylo možné využít rezervační části systému, je vždy nutné udržovat informace o všech podstatných zdrojích, např. časové obsazení kadeřníků. To je samozřejmě cílem i této práce. Jedná se o část aplikace, kterou ovládá operátor, jenž vidí všechny požadavky, zařazuje nové, případně upravuje požadavky již existující. Prostředí využívané operátorem musí být přehledné, rychlé a pokud možno jednoduše ovladatelné. Výhodou nutnosti udržovat všechny požadavky v systému je jejich vedlejší využitelnost: generování statistiky vytížení zdrojů, získávání informací o objednávkách, přehled klienta o vlastních objednávkách a možnost jejich změny či zrušení. Protože každým zdrojem, který se v salónu musí rezervovat, je člověk, je nutné počítat s požadavky na různou délku pracovní doby a např. s možností nenadálého onemocnění - a tedy rušení již objednaných návštěv. Výsledný systém musí jeho správci umožnit jednoduchou změnu otevírací doby, zadávání dnů, kdy je salón uzavřen, přidávání a editovaní osoby a nabízených služeb. Správce systému nebude muset mít předchozí administrátorské zkušenosti, aby dokázal výše zmíněné procedury využívat. V následujících částech 2. kapitoly bylo čerpáno z 8.1.

2.1 Současné fungování kadeřnického salónu Než se aplikace začala vyvíjet, navštívili jsme fungující salón Dessange Prague a zjišťovali jsme, jak funguje. Z rozhovorů s operátorkou a hlavním kadeřníkem vyplynulo následující. Salón nabízí kadeřnické, kosmetické, pedikúrní a manikúrní služby. Obsluhuje i zahraniční zákazníky, protože je součástí známého evropského řetězce salónů. Doposud využívá formu osobního či telefonického objednávání klientů, návštěvy jsou zaznamenány do kalendáře. Případné změny jsou řešeny vymazáním záznamu, což může vést ke snížené přehlednosti. Každá strana diáře zachycuje jeden pracovní den, ve sloupcích jsou uvedeni zaměstnanci a jednotlivé řádky znázorňují pracovní hodiny. Vedle jména zákazníka se zapisuje telefonní kontakt, požadované služby a případná poznámka týkající se klienta. Pokud se provádí rezervace, zákazník mívá požadavek na preferenci personálu a dobu návštěvy, ale má tendenci se přizpůsobit. Proto operátor, který objednávky zaznamenává, nenabízí termíny všechny, ale jen některé. Rezervace je nutná pouze u kadeřníka a kosmetičky; služby manikérky a pedikérky jsou dostupné vždy. Některé služby lze provádět současně, čímž se zkracuje celková doba návštěvy. Za jistých okolností tedy mohou pro jednoho zákazníka pracovat ve stejný okamžik jak např. kosmetička, tak kadeřník. „Synchronizace“ záznamů v kalendáři On-line rezervační systém 3

Úvodní studie

operátora a v kalendářích jednotlivých členů personálu (mají možnost přijímat zakázky i individuelně) je poněkud krkolomná, zřídkakdy ovšem dochází ke kolizi objednávek. Klientela se skládá ze stálých (více jak polovina), ale i náhodných zákazníků. Není-li klientem požadován konkrétní pracovník, je přidělen ten, který má „opticky“ nejméně práce (výpočty vytíženosti se neprovádějí). Při rezervaci není potřeba brát zřetel na kapacitu prostor, je dostatečná. Čas vymezený jednomu zákazníkovi se odvíjí od množství jím zvolených procedur a je vždy zaokrouhlen na celé půlhodiny.

2.2 Scénáře chování uživatelů Scénáře chování uživatelů (zákazníků a operátorů) při používání elektronického systému rezervací ukazují několik základních postupů. Předpokládejme použití pro kadeřnický salón a odpovídající služby. Náhodný návštěvník portálu salónu zjistí, že se lze rezervovat on-line. Není registrovaný a protože neví, jestli mu systém navrhne vhodný termín, ani se registrovat nechce. Projeví zájem o mytí, barvení a střih vlasů, a protože v salónu nikdy nebyl, nepreferuje obsluhu. Jedním z požadavků zadavatele bylo nezveřejňovat vytíženost personálu, a proto si zákazník nemůže zvolit konkrétní hodinu. Může preferovat den v týdnu, jeho část a časové rozpětí. V našem případě je například vyhovující úterý dopoledne a středa odpoledne. Po odeslání systém zpracuje požadavky, oznámí cenu, dobu potřebnou pro vykonání preferovaných služeb a navrhne termíny. Uživatel si vybere některý z navržených termínů a potvrdí volbu. Na poslední stránce rezervačního formuláře je sumář zvolených služeb, cena, termín a očekávaná doba. Uživatel není přihlášen, proto mu systém navrhne tři varianty identifikace – zaregistrovat se, přihlásit se (pokud je již zaregistrovaný) nebo zapsat příjmení a telefonní číslo, pokud se nechce registrovat. V případě poslední varianty ho operátor salónu bude telefonicky kontaktovat, aby ověřil, že se nejedná o smyšlenou rezervaci. Další návštěvník již je registrovaný, objednává se každý měsíc, má svého oblíbeného kadeřníka. Pamatuje si, že po minulé návštěvě mu všichni chválili barvu vlasů. Při rezervaci ale nedokáže určit, jaký typ barvení zvolil, musí proto nahlédnout do historie návštěv. Ostatní požadavky zaznamená během jedné minuty a pokračuje dalším krokem – volbou konkrétního termínu. Zvolené služby musí provést jak kadeřník, tak kosmetička, a proto je problém nalézt termín, který vyhovuje časovému zadání. Systém prohledává časové možnosti preferovaného kadeřníka a všech kosmetiček tak, aby odpovídaly zvoleným požadavkům. Navíc lze skloubit sušení hlavy a manikúru, celkový čas je tedy kratší než součet časů potřebných na jednotlivé úkony. Po ukončení a uložení rezervace přichází zaregistrovanému uživateli potvrzovací email. O právě provedené on-line rezervaci přijde email také operátorovi a ten na jeho základě zkontroluje, zda systém obsadil personálu čas správně. Při paralelní činnosti, která probíhá u této návštěvy, je potřeba upravit dobu personálu, protože jak kadeřníkovi, tak kosmetičce byla zabrána doba celého trvání návštěvy. Operátor kromě kontroly systémem přiděleného času také rezervuje požadavky zadané telefonicky. Objednat volající osobu může buď konkrétním zvolením služeb, personálu, termínu i doby, nebo si nechá najít termín stejným způsobem jako uživatelé, když si rezervují návštěvu. Mezi základní operace operátora patří i přeobjednání a smazání návštěvy.


Úvodní studie

2.3 Texty úvodní studie 2.3.1 Deklarace záměru Cílem práce je navrhnout a implementovat softwarový produkt, který usnadní a zpřehlední plánování návštěv kadeřnického a kosmetického salónu jak zákazníkovi, tak jednotlivým zaměstnancům. Zákazník si bude mít možnost 24 hodin denně rezervovat, přeobjednávat i rušit služby konkrétního pracovníka salónu (tedy kadeřníka, kosmetičky, pedikérky a manikérky). Zároveň systém nesdělí uživatelům, jak jsou jednotliví pracovníci salónu a salón jako celek vytíženi. Personál salónu bude mít přehled o objednávkách, ve kterých figuruje, bude mít právo si upravovat pracovní dobu. Vybraný personál bude mít přístup ke statistikám návštěv, zvlášť k přehledu všech návštěv zobrazených v kalendáři, a bude moci návštěvy zakládat, měnit a rušit. Pro správce aplikace bude připraveno rozhraní, v němž bude editovat, zadávat a rušit jednotlivé služby salónu, personál a pracovní hodiny salónu jako celku. Uživatel bude k datům přistupovat pomocí prohlížečů internetových stránek.

2.3.2 Odborný článek Hlavní motivací projektu je požadavek Dessange Prague na centralizaci a archivaci provedených služeb a na možnost jednotlivých zákazníků rezervovat si, měnit a rušit návštěvy bez nutnosti komunikace s personálem. Aplikace by měla usnadnit orientaci a editaci v databázi návštěv. Systém bude spravovat návštěvy v salónu krásy, který nabízí kadeřnické a kosmetické služby, manikúru a pedikúru. Tyto služby (procedury) se mohou libovolně kombinovat a všechny budou provedeny během jedné návštěvy klienta. Provádí je omezený počet kadeřníků a ostatních pracovníků. Jejich čas je nutno rezervovat a přiřadit jednotlivým návštěvám klientů. Personál nemusí pracovat po celou dobu, kdy je salón otevřen. Může mít vlastní pracovní dobu, kterou lze omezit případnou dovolenou. Člen personálu může obsluhovat pouze jednu osobu, ale jedné osobě se může zároveň věnovat více zaměstnanců. Pracovníci salónu mohou díky své kvalifikaci obsáhnout více činností, tj. poskytovat např. služby kosmetické i kadeřnické. Rezervace provedená zákazníkem On-line rezervace bez účasti personálu proběhne následujícím způsobem. Zákazník zvolí procedury a přibližný termín návštěvy, který mu vyhovuje. Systém vypočítá délku všech úkonů a určí, lze-li některé provádět současně (alespoň u dvou úkonů bude uvedeno, že je možné je kombinovat) a je-li potřeba rezervovat čas dvou různých osob personálu. Personál je volen buď přímo zákazníkem, nebo určen na základě aktuální vytíženosti. Systém neřeší, zda druhá osoba potřebuje ke splnění požadavku zákazníka kratší dobu než první, a bude vyhledávat časové okénko u obou pracovníků velikosti alespoň délky všech úkonů. Pokud nebyl preferován personál, systém zkusí najít čas postupně u všech osob poskytujících zvolené procedury. Nenajde-li se volný termín, bude uživatel požádán o snížení nároků na konkrétnost termínu. V případě nalezení volných termínů se jich zobrazí maximálně pět. Po zvolení jednoho z nich se klient ještě autorizuje a objednávka je potvrzena. Autorizace proběhne buď přihlášením do systému (po registraci), nebo zákazník uvede jméno s telefonním číslem, na On-line rezervační systém 5

Úvodní studie

kterém se operátor zpětným zavoláním ujistí, že jde o skutečnou rezervaci. Všechny systémem vytvořené objednávky operátor zkontroluje, případně upraví časy obsazení konkrétního personálu tak, aby byl u dané návštěvy v pravý čas (mytí vlasů předchází barvení a při barvení lze upravovat nehty). Nezamění však čas začátku návštěvy. Při registraci nového klienta bude systém vyžadovat minimum údajů; jméno, příjmení, email, telefonní číslo a přihlašovací údaje (uživatelské jméno a heslo). Po provedení registrace se odešle mail se všemi údaji včetně hesla na uvedenou emailovou schránku. Uživatel bude mít možnost jakýkoliv údaj uvedený při registraci později změnit. Každý klient bude moci kontrolovat plán i historii svých návštěv. Návštěvy, které ještě neproběhly, je možné den předem zrušit nebo přeplánovat. Při přeplánování je využito procesu totožného s rezervačním - všechna pole už jsou „předvyplněna“ podle právě zrušené rezervace (přeplánování zahrnuje zrušení rezervace, protože tím se uvolní prostor pro rezervaci novou - ta se s původní může překrývat)1. Personál bude mít možnost nahlédnout do svého kalendáře naplánovaných akcí, bude do něj moci přidávat návštěvy, editovat je či rušit (jakým způsobem viz níže). Přestože neuvidí rozvrh práce ostatních zaměstnanců, může si je volit jako spolupracovníky. Kalendář bude mít stejný vzhled jako dosud používaný a bude shodný s kalendářem operátora. Pracovní doba zaměstnanců se liší, proto si každý může nastavit svoji individuální pracovní dobu. Navíc si zaměstnanec bude moci vyhradit časový prostor v pracovní době, do kterého se nebudou vkládat nové návštěvy. Využití této možnosti se předpokládá především při plánování termínu dovolené. Neuskutečněná dovolená půjde zrušit nebo editovat a bude stejně jako dovolená již vyčerpaná zobrazena k prohlížení. Kalendář Stěžejní částí aplikace je kalendář. Plně nahradí doposud užívaný neelektronický, a proto mu bude maximálně podobný. Den bude rozdělen do tabulky, ve které každý řádek představuje půl hodiny pracovní doby (minimální doba trvání návštěvy) a sloupce tabulky personál (jeden člen personálu je jeden sloupec o tolika řádcích, kolik má otevírací doba salónu půlhodin). Kalendářem půjde rychle listovat a bude možno zobrazit plán práce jen některého zaměstnance (i na více dní). Každá zaznamenaná schůzka v kalendáři bude lehce zobrazitelná a editovatelná. O návštěvě se zaznamenávají tyto informace: příjmení a jméno zákazníka, obsluhující personál, zvolené procedury pro jednotlivé členy personálu, datum, začátky a konce obsluhy konkrétního personálu, poznámka a značka kontroly. Značka kontroly potvrzuje, zda byla návštěva objednaná systémem zkontrolována operátorem. Operátor bude mít navíc možnost listovat výpisem všech návštěv (zobrazeným mimo kalendář) a bude v něm moci vyhledávat. Pro přehled o práci jednotlivých zaměstnanců budou sloužit statistiky vytíženosti, které za zvolený časový úsek zobrazí poměr odpracované doby k době pracovní.

1

Výhledově by systém přeobjednání měl řešit tak, že právě přesouvanou návštěvu označí za neplatnou, ale pokud by si uživatel přál, může ji v případě volného termínu opět obnovit.


Úvodní studie

Správce aplikace Osoba zodpovědná za chod aplikace bude mít právo přidávat, editovat a mazat jednotlivé zaměstnance i procedury. Každému zaměstnanci bude moci editovat pracovní dobu, bude editovat otevírací hodiny celého salónu včetně přidávání a editace dnů uzavření salónu. Mezi další požadavky zadavatele patří ukládání každého přihlášení uživatele do databáze. Aplikace se nezabývá blokací „křesel“ a použitých nástrojů, materiálu. Současný klient salónu je především ženského pohlaví a nepředpokládá se, že je zkušeným uživatelem internetu a počítače vůbec. Z toho plynou požadavky na systém, který musí být ovladatelný jen se základními znalostmi internetových služeb.

2.4 Hlavní rysy aplikace Pokud bychom měli v bodech shrnout základní požadavky na systém, jsou to tyto:  Nebude implementováno rozhraní aplikace, ale využije se prohlížečů www stránek, veškerá nastavení včetně údržby systému bude možno provést i mimo firmu.  Rezervace návštěvy zákazníkem bude jednoduchá s minimálními požadavky na identifikaci zákazníka.  Prostředí pro správu všech návštěv bude uzpůsobeno tak, aby operátor mohl návštěvu rezervovat, změnit či odstranit a změnu potvrdit během jednoho telefonického hovoru.  Prostředí operátora nahradí současné kalendáře, v nichž jsou rezervace zaznamenány.  Nastavení služeb, personálu a pracovní doby bude implementováno v hlavní aplikaci.  Personál bude mít přehled o svých zakázkách a na případné rezervace bude upozorňován.  Zákazníci budou mít přehled o historii i plánu svých návštěv.


Úvodní studie

2.5 Diagram kontextu Zákazník

1.B

Personál

1.A

Databáze

2.B 2.A

6.B Systém salónu

6.A

5 SMTP server

3.B 4.A 4.B

3.A

Administrátor

Privilegovaný personál

Obr. 1 – Diagram kontextu

Diagram kontextu (Obr. 1) zobrazuje aktéry a jejich datové toky. Systém bude ke své činnosti potřebovat dva externí servery – databázový, SMTP mail server a aplikační server, přičemž mohou všechny fungovat na jednom fyzickém stroji. Jednotlivé požadavky jsou dále rozebrány. 1.A registrace uživatele, přihlášení a odhlášení do a z systému, editace uživatele, rezervace návštěvy, přeplánování návštěvy, zrušení návštěvy, prohlížení návštěv 1.B potvrzení registrace, přihlášení, rezervace, smazání rezervace; zobrazení volných termínů, návštěv uživatele, nastavení 2.A vložení nové návštěvy, editace a smazání návštěvy, nastavení pracovních hodin, zobrazení pracovních hodin, plánovaných návštěv a detailu návštěvy 2.B potvrzení vložení, editace a smazání návštěvy, zobrazení pracovních hodin, dnů dovolené a naplánovaných schůzek, zobrazení detailu jednotlivých návštěv 3.A vkládání, editace, mazání personálu a nabízených procedur, editace otevíracích hodin salónu i personálu a prohlížení všeho zmíněného 3.B potvrzení provedených změn, zobrazení personálu a služeb, zobrazení otevíracích hodin i pracovní doby personálu 4.A vložení nové, editace a mazání již existující návštěvy u libovolného personálu, prohlížení plánu práce všech zaměstnanců včetně detailu návštěv, prohlížení statistik, nastavení priority přidělování personálu 4.B potvrzení úprav a změn na jednotlivých návštěvách, zobrazení vybraných statistik a plánů práce 5. požadavek na odeslání potvrzovacích a informativních mailů 6.A jsou veškeré dotazy do databáze On-line rezervační systém 8

Úvodní studie

6.B výsledky jednotlivých dotazů

2.6 Případy užití Diagramy případů užití vznikaly postupně s narůstajícími požadavky na funkčnost systému od obecných až po konkrétní požadavky. Zjednodušené, tzv. zlaté diagramy případů užití (jsou zde znázorněny ty případy užití, které jsou nutné k pochopení funkčnosti, ale neobsahují všechny případy, které je nutné implementovat) jsou znázorněny dále. Rozklad probíhal metodou odshora dolů, tedy obecně navrhnutá funkčnost byla rozdrobena na jednotlivé požadavky. Ze zadání vyplynuli čtyři aktéři, přičemž hierarchicky výše postavený aktér „dědí“ případy užití od hierarchicky níže postavených. Na Obr. 2 je hierarchie znázorněna šipkou směřující od výše postaveného aktéra. Jednotlivé případy použití jsou seskupeny pod obecný, skupinu vystihující popis. Na dalších ilustracích jsou skupiny rozvedeny. Přihlásit uživatele Odhlásit uživatele

Uživatel

Spravovat údaje o uživateli

Spravovat zaměstnancův plán práce Spravovat zaměstnancovy pracovní hodiny

Spravovat uživatelovy rezervace

Registrovat uživatele

Zaměstnanec

Prohlížet historii návštěv Prohlížet statistiky

Privilegovaný změstnanec

Spravovat plán práce

Spravovat otevírací dobu Spravovat zaměstnance Spravovat služby

Správce systému

Obr. 2 – Případ užití nejvyšší úrovně


Úvodní studie

2.6.1 Případ užití pro aktéra Uživatel Uživatel je kdokoliv, kdo přijde do kontaktu s aplikací. Ostatní aktéři jsou privilegovaní a do systému je může přidat pouze správce systému. Provedení většího rozkladu diagramu budeme realizovat po jednotlivých aktérech. Uživatel je základní aktér, jeho případy použití (Obr. 3) mají všichni ostatní aktéři v systému – jsou od uživatele odvozeni. Za zmínku stojí přeplánování a zrušení rezervací, protože je nelze provést bez prohlížení rezervací. Ostatní akce jsou na sobě nezávislé a jejich smysl plyne z kapitoly 2.3.2.

2.6.2 Případ užití pro aktéra Zaměstnanec Zaměstnanec má oproti uživateli navíc správu vlastních pracovních hodin a správu vlastního plánu práce. Slovo vlastního je velmi podstatné tím se zaměstnanec odlišuje od privilegovaného zaměstnance. Veškerá správa návštěv se děje nad kalendářem zaměstnance. Při prohlížení si zvolenou návštěvu může zobrazit v detailu a začít ji editovat. Mazání proběhne bez nutnosti zobrazit návštěvu a bude ji předcházet otázka, zda si je operací jistý. Viz. Obr. 4. Případ užití pro aktéra Privilegovaný zaměstnanec Diagram privilegovaného zaměstnance získává navíc tři případy použití, ale jedná se především o prohlížení statistik a návštěv. Může ovšem spravovat plán jakéhokoliv zaměstnance, z čehož plyne, že má přehled nad děním v celém salónu. Díky přehledu přijímá, edituje většinu objednávek. Případ užití Spravovat plán práce privilegovaného zaměstnance využívá vazby <> na případ užití Spravovat zaměstnancův plán práce.

<<extends>> Přihlásit uživatele Odhlásit uživatele

Přeplánovat rezervaci <>

<<extends>>

Prohlížet rezervace

<> Spravovat uživatelovy rezervace

<<extends>>

<<extends>>

Uživatel

Spravovat údaje o uživateli

<<extends>>

<<extends>>

Zrušit rezervaci Vytvořit rezervaci Prohlížet detaily uživatele Editovat uživatele


Obr. 3 – Diagram případu užití uživatele


Úvodní studie

<<extends>>

<<extends>>

<<extends>>

Spravovat zaměstnancův plán práce

Spravovat zaměstnancovy pracovní hodiny

Prohlížet naplánévané návštěvy Editovat návštěvu Smazat návštěvu

<<extends>> <<extends>>

Zaměstnanec

Přidat návštěvu

<<extends>>

Zobrazit pracovní hodiny Editovat pracovní hodiny

<<extends>> Přidat volno <<extends>>

<<extends>>

Editovat naplánované volno Zobrazit naplánované volno

Obr. 4 – Diagram případu užití zaměstnance

2.6.3 Případ použití pro aktéra Správce Správce je aktér, který udržuje veškerou nabídku služeb a personálu. Při registraci nového člena personálu se zároveň založí nový klient, proto je zde vazba na Registrovat uživatele. Správce může zadávat otevírací hodiny včetně případných uzavírek a svátků. Diagram případů pro aktéra správce je na Obr. 5.

2.7 Stanovení dosažitelných cílů pro tuto diplomovou práci Práce na samotném systému on-line rezervací služeb salónu krásy začaly již dlouho před tím, než jsem se rozhodl s tímto projektem spojit téma své diplomové práce. Původně jsme si toto téma zvolili s kolegou Jiřím Tománkem jako semestrální práci na podzim roku 2005. Součástí zadání již tehdy byl požadavek na práci v pro nás neznámém rámci Jakarta Struts (podrobněji v kapitole 3.6.1). Semestrální projekt tedy sloužil spíše k seznamování se s tímto rámcem, jeho provozem na serveru a pochopení nutných nastavení. Součástí semestrálního projektu byla zevrubná analýza problému a především intenzivní komunikace se zadavatelem včetně návštěvy fungujícího salónu.


Úvodní studie

<<extends>>

Spravovat pracovní hodiny

<<extends>>

Spravovat zaměstnancovy pracovní hodiny

Spravovat otevírací dobu


<> <<extends>> Přidat personál

Správce

Spravovat personál

<<extends>> <<extends>>

Spravovat služby

<<extends>>

Editovat personál Mazat personál Přidat službu

<<extends>> Editovat službu <<extends>>

Smazat službu

Obr. 5 – Diagram případu použití správce aplikace

Výsledkem semestrální práce byla kostra současné rezervace návštěvy uživatelem i personálem, fungující s velkými nedostatky. Během práce se totiž ukázalo, že požadavky a rámec Struts (jeho neznalost) vývoj projektu výrazně zpomalily. Jiří Tománek se věnoval části personálu a registraci, já jsem vyvíjel rezervaci pro klienty a nastavení systému. Vedoucím projektu byl ing. Zdeněk Míkovec. Protože se zdálo, že výhody Struts mají teprve přijít, resp. že k tomu hlavnímu jsme se nestihli propracovat, rozhodl jsem se na projektu pokračovat v rámci předmětu Návrh a implementace uživatelského rozhraní. Jak název napovídá, věnoval jsem se především části pro zákazníka a snažil jsem se do projektu vnést přehlednost a přívětivost systému k uživateli. Byla dopsána část nastavení otevíracích hodin, nastavení personálu i služeb. Všechny části měly využít validace, která by ve Struts měla mít výbornou podporu. V této fázi projektu nastalo zdržení kvůli špatnému návrhu Struts resp. špatnému napsání projektu pro Struts. Projekt tehdy již obsahoval minimální funkčnost nutnou k provozu aplikace, ale především část, na které se do předmětu Návrh a implementace uživatelského rozhraní nepracovalo (část pro operátora), byla uživatelsky nepřívětivá. Cílem mé diplomové práce je dovést tuto aplikaci do stavu, který bude odpovídat alfa verzi finálního produktu. Bude tedy bude odladěná a připravená na testy použitelnosti (Usability test, viz 8.1), které odhalí případné nedostatky.

2.7.1 Plán nutných úprav Je potřeba přepracovat sekci operátora a přidat funkce usnadňující změnu termínu, personálu a času. Zobrazení vytíženosti personálu bude parametrizovatelné (bude možno zobrazit volitelný počet personálu na volitelný počet dnů), sestavení stránky by se mělo zrychlit. Využití technologie Ajax zrychlí práci při zadávání volajícího zákazníka


Úvodní studie

(našeptávání) a zvýší přehlednost a bezpečnost aplikace tím, že nabízené hodiny začátku a konce budou pouze ty, které lze zadat. Přibude spolupráce dvou lidí na jedné návštěvě. Vytvoří se stránka s historií návštěv pro uživatele, stránka přehledu práce pro jednotlivé zaměstnance, stránka statistik včetně grafického zobrazení vytíženosti. Personál bude nabízen na základě vytíženosti během určité doby, hodnoty se budou automaticky aktualizovat. Při zadávání dovolené se bude provádět kontrola, není-li již na stejný termín vznesen jiný požadavek, a pokud ano, bude nabídnuto řešení vzniklých konfliktů. Provádění rezervací, jejich změn a upomínání na ně bude potvrzováno emaily. Mimo rámec diplomové práce stojí výsledný vzhled aplikace, přesto se vytvoří design použitelný pro testování, jehož součástí bude i plný překlad do anglického jazyka.


Analýza

3 Analýza V této části textu budou zformulovány analyzované požadavky na funkčnost systému tak, aby byl schopen nahradit současné řešení záznamu plánu návštěv a výrazně usnadnit zákazníkům i zaměstnancům přehled o časovém rozvrhu. Výsledkem analýzy bude katalog požadavků a z něho vyplývající návrh databáze, který je velmi podstatný pro funkčnost systému. Proces zjišťování požadavků na systém se skládal z několika schůzek se zadavatelem. V první byly nastíněny požadavky zadavatele. Na druhou schůzku jsme si připravili návrh 2 průchodu aplikací při objednávání uživatelem, který jsme z požadavků vytušili. Nad tímto návrhem se rozvinula diskuze, na jejímž základě se objevilo hned několik dalších požadavků. Abychom mohli analyzovat část operátora, tj. osoby, která zadává do kalendáře objednávky, a zároveň pochopili fungování salónu, salón jsme navštívili a informace získávali přímo od zaměstnanců, mj. od osoby zodpovědné za vedení kalendáře. Návštěva měla velký přínos pro následný vývoj, protože jsme se snažili funkčnost přiblížit doposud používanému nedigitálnímu záznamu. Po dosažení dílčích vývojových verzí jsme provedli další konzultace se zadavatelem a vedoucím práce.

3.1 Současné řešení Fungování salónu bylo nastíněno v kapitole 2.1, připomeneme základní informace. Současná data jsou udržována pouze záznamem v papírovém kalendáři, navíc nejsou konzistentní, protože personál může přijímat objednávky do svého kalendáře, který se několikrát denně „synchronizuje“ s hlavním kalendářem. Veškeré objednávky jsou vytvářeny maximálně měsíc předem. Dobu trvání návštěvy personál „určí zkušeným odhadem“, ale protože se rezervuje vždy na celé půlhodiny, ke „skluzům“ téměř nedochází.

3.2 Katalog požadavků 3.2.1 Požadavky na software Celý systém bude ke své funkčnosti vyžadovat aplikační server a databázový server. Volba obou serverů byla ovlivněna především cenou, kvalitou produktu a kladnými referencemi (např. 8.2). Výběr databázového systému MySQL 5.0 byl jednoznačný především díky nenáročnosti na hardware, rychlosti a stabilitě (jak je uvedeno na 8.2) vzhledem k nulovým pořizovacím nákladům – databáze je dostupná pod licencí GPL3. Zároveň nepředpokládáme 2 3

Návrh je umístěný na přiloženém CD v adresáři others. General Public Licence


Analýza

velké vytížení, a tak je investice do ověřených systémů zvládajících obrovské vytížení prozatím zbytečná JBOSS v 4.0 (8.2, 8.2) byl za aplikační server zvolen především kvůli možnosti re-deploy (opětovné nahrání) zdrojového kódu bez nutnosti celý server restartovat, což se bylo nesmírně výhodné především při vývoji a dále díky podpoře Service Archive format (SAR), který umožňuje bezproblémově naplánovat periodicky se opakující rutiny. Navíc je to open source systém s nulovými náklady na pořízení.

3.2.2 Požadavky na hardware Výhodou řešení veškerých výpočtů na straně serveru ve web kontejneru je nenáročnost na HW klientských stanic. Zákazníkům bude stačit prohlížeč a připojení k Internetu, přímo do salónu bych doporučil stanice s minimálně 256MB RAM a procesor o taktu alespoň 1GHz. Je to kvůli náročnosti prohlížeče Mozzila Firefox (předpokládejme verzi pro MS Windows XP), pro který je firemní část aplikace optimalizována, a také proto, že lze očekávat více otevřených oken (panelů) prohlížeče zároveň (dosáhne se tím rychlejšího listování po jednotlivých dnech). Počítač operátora bude mít větší požadavky na rychlost odezvy, proto doporučuji min. 512MB RAM (zamezení „swapování“) a procesor o taktu 2 GHz nebo ekvivalentní, aby bylo minimalizované zdržení při otevírání oken prohlížeče. Nejpodstatnější součástí operátorova stroje bude monitor, respektive velikost jeho úhlopříčky a počet zobrazovaných bodů. Aby bylo pohodlně zobrazeno dvanáct zaměstnanců ve dvou dnech, je potřeba rozlišení monitoru alespoň 1600*1xxx, kde výška obrazu přes tisíc obrazových bodů je dostačující. Z tohoto důvodu je doporučen širokoúhlý monitor o úhlopříčce minimálně dvaceti palců. Připojení k serveru, pokud nebude ve stejném objektu jako stanice (zde potom využijeme místní síť), musí být s minimální latencí, která by měla negativní vliv na využití technologie AJAX. Již zmíněný diář zobrazující dvanáct zaměstnanců na dva dny má velikost mezi 100kB a 200kB, takže minimální rychlost spojení by měla být 4Mbit. Toto připojení by mělo mít garantovanou stabilitu. Na druhou stranu všechnu práci musí vykonat server a zde je odhad na HW předčasný, protože ještě nebyly provedeny zátěžové testy. Pokud nebude možno garantovat rychlé a stabilní připojení k serveru a bude potřeba optimalizovat náklady, je možné využít stolního PC s dostatečnou kapacitou operační paměti jako serveru a operátorovi stanice zároveň. Ušetří se tak čas, po který by data putovala od serveru ke stanici. Navíc zadavatel odhadoval klientelu v řádu stovek osob, což není mnoho, a vzhledem k tomu, že se jejich požadavky pravidelně opakují a jsou rovnoměrně rozloženy do přibližně stejné periody (od návštěvy k návštěvě), obavy z přetížení serveru nejsou na místě. Větší zátěž než klienti vytvoří opakovaně se obnovující operátorova část aplikace. Proto zpočátku raději preferujeme rychlost operátorova spojení před spojením ostatních uživatelů. K těm se ve výsledku přenáší stránky řádově menší velikosti než zmíněný diář.

3.3 Požadavky na vytvářený software V dalších odstavcích jsou shrnuty požadavky na vytvářený systém, které vyplynuly z úvodní studie. On-line rezervační systém 15

Analýza

3.3.1 Informace udržované v databázi Uživatel  Jméno  Příjmení  Přihlašovací jméno – jedinečné. Pokud bude registrováno více zákazníků se stejným jménem i příjmením, bude použito k jednoznačnému určení zákazníka.  Heslo  Telefonní číslo – V případě nepředvídatelných událostí bude zákazník na tomto čísle informován o změnách plánované návštěvy  Titul  Kontaktní email – na tento mail budou chodit potvrzení o rezervaci a její změně  Poznámka – slouží k identifikaci zákazníka personálem („krátkovlasá blondýna“) při shodě jmen, personál nezná přihlašovací jména, prozatím neimplementováno  Perioda návštěvy – zda si uživatel přeje připomínat, že by měl znovu navštívit salón, prozatím neimplementováno  Role – definuje práva uživatele (uplatněno především u personálu)  Datum a čas přihlášení do systému Personál V ISA hierarchii je personál pod uživatelem, takže každý personál je uživatel.  Jméno – bude zobrazeno v diáři, lze použít přezdívku, protože úplné jméno je uloženo v odpovídajícím uživateli  Příjmení – bude zobrazováno v nabídkách pro uživatele, možno použít pseudonym  Telefon – pracovní telefon  Pracovní email  Viditelnost – je-li to personál viditelný pro zákazníky  Priorita – určuje pořadí, ve kterém se personál bude nabízet zákazníkovi  Manuální priorita – povoluje nastavit prioritu a ta se nebude přepočítávat  Obor práce, který personál ovládá o Kadeřnictví o Kosmetika o Pedikúra o Manikúra  Pracovní doba o Každý den určit čas od a čas do kdy se mohou lidé objednávat o Den volna – pokud celý den nepracuje  Vytíženost personálu – poměr odpracovaných hodin ku délce pracovní doby Služby  Jméno služby – pokud se nenajde ekvivalentní přiřazení jména ve vhodném jazyce, bude zobrazeno v nabídce  Popis služby – opět klíč do souborů s jednotlivými jazyky, případně jednou větou popsaná procedura  Cena – cena účtovaná za tento úkon On-line rezervační systém 16

Analýza

   

Délka procedury v minutách Doba z délky procedury, která je možno využít k jiným procedurám Viditelnost služby – zda je služba nabízena Druh služby – jedna z možností – kadeřnická, kosmetika, pedikúra a manikúra

Návštěva  Datum  Začátek –čas, kdy personál začíná obsluhu  Konec – čas, do kdy by měly být všechny procedury ukončeny  Potvrzení – každou objednanou návštěvu musí potvrdit personál  Připomínka – zda se má posílat email připomínající dohodnutou návštěvu  Jméno neregistrovaného  Telefon neregistrovaného – poslední dvě se týkají objednávek nepřihlášených uživatelů.  Poznámka – libovolná textová poznámka k návštěvě (číslo barvy na vlasy)  Preferovaný den – dny, které byly zvoleny při zadávání hledání termínu  Preferovaná část dne – části dne, které byly zvoleny při zadávání hledání termínu  Preferovaný personál který byl zvolen při zadávání hledání termínu Informace o salónu  Otevírací doba  Dny uzavření salónu – státní svátky, inventury…

3.3.2 Správa dat Část dat v databázi bude volně editovatelných, část půjde editovat pouze v určitých případech a zbytek editovat nepůjde vůbec. Vkládání (zakládání) dat Zákazník vytvoří svou objednávku ve třech krocích (celý postup bude probrán podrobněji v kapitole 5.3.1), během kterých mu budou nabídnuty všechny hodnoty potřebné k vytvoření plnohodnotné návštěvy. Registrací zákazník zadá informace o své osobě. Personál bude mít možnost vložit všechny přípustné hodnoty nutné pro návštěvu na jednom formuláři. Bude moci vkládat své dny volna. Administrátor bude moci vkládat nové uživatele, služby a dny volna pro personál i samotný salón. Přehled dat, které lze editovat Patří sem především nastavení aplikace, které bude moci provádět pouze osoba s právy administrátora. Jedná se o editaci personálu, u kterého je možné editovat všechny zmíněné položky udržované v databázi. Také editace služeb bude možná v plném rozsahu jen s tím, že pokud bude editován název a popis služby, bude nutné doplnit ekvivalent v dalších jazycích, které systém bude podporovat. Samozřejmostí bude editace otevíracích hodin salónu. Plánované volno půjde editovat pouze pokud ještě neproběhlo.


Analýza

Změnu hodnot u návštěvy bude možné provést operátorem v plném rozsahu, ovšem zaměstnanci pouze u návštěv jim určených. Pro správu návštěv, kterou zaměstnanec neobsluhuje, bude třeba specifická role. Personál dále může editovat své pracovní hodiny a nevyčerpanou dovolenou. Zákazník bude moci editovat pouze své nastavení, měnit hodnoty svých návštěv moci nebude. Přeplánování návštěvy bude znamenat smazání vybrané a vytvoření nové. Náhledy na data Specifický bude především pohled na návštěvy, který nahradí doposud používaný papír a tužku. Přehlednost, jednoznačnost a relativní rychlost zobrazení je rozhodující. Celý pohled na kalendář bude tabulka, jejíž sloupce znázorňují jeden pracovní den jednoho zaměstnance a řádky rozdělují den po půlhodinách. Déle trvající návštěva bude jedna velká buňka tabulky přes více řádků jednoho sloupce. Náhledy na statistiky, sumář návštěv a dovolené bude možno zobrazovat po omezeném množství výpisů na stránku a vybrané sloupce bude možno řadit. Ze stručných výpisů bude moci být vybrána skupina dat, kterou systém zobrazí podrobněji.

3.3.3 Automatické rozesílání emailů Při registraci, rezervaci, změně rezervace či zrušení rezervace bude zaregistrovanému uživateli doručen informační email. Navíc se budou rozesílat emaily, které budou připomínat, že následující den je klient v salónu očekáván.

3.3.4 Automatický výpočet vytíženosti Rozložení pracovní vytíženosti zaměstnanců by mělo být rovnoměrné. Proto se budou každou hodinu přepočítávat statistiky vytíženosti, na jejichž základě bude určeno pořadí přidělování personálu zákazníkům, kteří nemají požadavek na konkrétní obsluhu.

3.3.5 Pomocné návrhy Bude-li personál zadávat jméno zákazníka, systém napoví celé jméno uživatele na základě shody vložených znaků se jmény z databáze. Při vybírání začátku návštěvy se zúží nabídka konce návštěvy jen na platné hodnoty (časy po začátku a zároveň před další návštěvou u zvoleného personálu).

3.3.6 Graf vytíženosti Pro lepší čitelnost bude systém kreslit jednoduchý koláčový graf.

3.3.7 Podpora více jazyků Překladem centralizovaných klíčů bude moci jednoduše doplnit další jazyk aplikace.


Analýza

3.4

Datová analýza

Provedení datové analýzy patří k základním stavebním kamenům aplikace. V této práci se požadavky na systém měnily v průběhu vývoje, ale díky rozumně navrženému základu databáze se původní návrh jen rozšiřoval.

3.4.1 ER diagram Z důvodů úspory místa při zobrazení ER diagramu (Obr. 6) jsem vypustil výpis datových typů (na přiloženém CD je vše). Podrobný rozbor tabulek je uveden v sekci Popis reprezentace dat. Relační vztahy mezi jednotlivými entitami jsou popsány na ER diagramu následujícím způsobem. V hranatých závorkách je uvedena dvojice hodnot oddělená dvojtečkou. Levá hodnota odpovídá tabulce účastnící se v relaci, která je více vlevo případně výše. Kvůli nesrovnalostem jsou za hranatými závorkami uvedeny názvy tabulek ve stejném pořadí, jako hodnoty definující mohutnost vztahu. Pokud je hodnota 0-x, je účast nepovinná.

3.4.2 Popis reprezentace dat V tabulkách jsou uvedeny klíče, povinnost nenabývat NULL hodnot, obor hodnot, implicitní hodnota a doplňující informací je poznámka. Všechny tabulky jsou typu TypeINNODB, pro který dokáže databáze MySQL 5.0 kontrolovat platnost cizích klíčů a v případě potřeby zabrání provedení operace. Níže jsou zobrazené vybrané tabulky, zbývající jsou v příloze 8.2. Název sloupce

Datový typ

Nenulov ý ANO ANO ANO NE NE NE NE

Default hodnota

int(10) varchar(45) char(1) int(10) int(11) text int(11)

Primární klíč ANO NE NE NE NE NE NE

Id_service name kind price duration description paralel visible

tinyint(4)

NE

ANO

1

Poznámka

Druh procedury

0

Čas z celkové délky, který je možno využít na provádění jiného úkonu. Kvůli konzistenci dat nelze service smazat

Tab. 1 - Entita service


Analýza

Obr. 6 - ER diagram


Analýza

3.4.3 Hodnoty dat a relace Hodnoty jednotlivých atributů, které mohou zůstat nevyplněné, budou mít implicitně hodnotu NULL. U datových typů, u kterých není hodnota NULL přípustná (jedná se především o různé rozsahy typu int), bude počáteční hodnota 0. Databáze MySQL nepodporuje typ boolean a nahrazuje jej malým rozsahem typu int. Hodnotu false reprezentuje 0, true je hodnota různá od 0. Výchozí hodnota pro primární klíče, kterým je přiřazena vlastnost auto-increment mimo vyplněné tabulky (číselník, user – viz dále) 1. Salón podporuje nepovinnost se registrovat, přitom ale jedním z cizích klíčů tabulky Event je právě id_user (z tabulky user). Aby byla zachována konzistence dat, je potřeba přidat uživatele s id_user = 0, který zastupuje v tabulce Event neregistrovaného uživatele, resp. pokud si rezervuje návštěvu neregistrovaný uživatel, bude mu propůjčeno id rovno 0. Při instalaci systému bude kromě neregistrovaného uživatele v databázi ještě uživatel s administrátorskými právy. Díky tomu nebude potřeba zasahovat do databáze jinak, než přes rozhraní systému. Všechny ostatní hodnoty jsou totiž nastavitelné a editovatelné s právy správce (administrátora). Id_role_de f 1 2 3 4

Value

name

1 5 10 15

user personal recepce spravce

Tab. 2 – Hodnoty a názvy rolí

V databázi bude jedna tabulka číselníků, která bude identifikovat role uživatelů. Rostoucí hodnota atributu Value bude zajišťovat větší práva v rámci systému. Mezi rolím přiřazenými hodnotami jsou záměrně mezery, aby bylo možno přidat další role, které budou definovat práva např. mezi správcem a recepcí. U telefonních čísel jsem záměrně zvolil textový datový typ, protože lze očekávat různé národní validace v jiných jazycích, tedy nelze se spolehnou na současnou validaci. Pro každé lokální nastavení systému bude potřeba editovat i validační výrazy. Důvodem, proč se v tabulkách vyskytuje redundantní údaj - a sice den (day) v týdnu, když z každého data lze určit, o jaký den v týdnu se jedná, je domněnka vzniklá při práci na první verzi salónu, že neustálé zjišťování, o který den v týdnu se jedná, by mělo za následek zpomalení hledání volného termínu. Měření prokázalo, že vyhodnocení dotazu, který není v cache paměti, je 2x rychlejší, pokud se použije hodnota day typu int, než když se nad každým datem provádí převod na dny pomocí MySQL funkce DAYOFWEEK(). Návrh tabulky personal se může jevit jako poněkud nešťastný. Obsahuje informace o schopnostech personálu vykonávat určité obory práce. Pokud bychom chtěli navrhnout databázi čistě, jistě bychom rozložili vztah personal – obor stejně jako je rozložen vztah user – role. Ze zadání však vyplynul konkrétní požadavek na omezení počtu oborů na právě čtyři, což umožnilo zjednodušit návrh a především implementaci.


Analýza

Název sloupce

Datový typ

id_user Login passwd Name surname Title Tel Email Hint Cycle

int(10) varchar(20) varchar(60) varchar(20) varchar(45) varchar(20) varchar(20) varchar(45) text int(10)

Primární klíč ANO NE NE NE NE NE NE NE NE NE

Nenulový

Poznámka

ANO ANO ANO ANO ANO NE ANO NE NE NE

Identifikace pro personál Navštěvuje pravidelně po x dnech

Tab. 3 - Entita user

Název sloupce

Datový typ

Nenulový

int(11) int(10)

Primární klíč ANO FK

Default hodnota

Poznámka

id_event user_id_user

ANO ANO

0

Neregistrovaný uživatel=0, dovolená =-1

Date Start Dnes commited

date time time tinyint(1)

NE NE NE NE

ANO ANO ANO ANO

0000-00-00 00:00:00 00:00:00 0

remind

char(1)

NE

NE

nr_surname

varchar(45)

NE

NE

nr_phone

varchar(20)

NE

NE

Day Pozn

tinyint(4) varchar(22)

NE NE

ANO NE

0

Tab. 4 - Entita event


Zda je zkontrolován operátorem Připomenout zákazníkovi emailem/telefonem Číslo neregistrovaného zákazníka Telefon neregistrovaného zákazníka Např. číslo barvy na vlasy

Analýza

Název sloupce

Datový typ

Primární klíč

Nenulový

Default hodnota

Id_closed date start

int(11) date time

ANO NE NE

ANO ANO ANO

0000-00-00 00:00:00

ends repeat

time tinyint(4)

NE NE

ANO ANO

00:00:00 0

day

tinyint(4)

NE

ANO

0

Poznámka

Každoročně se opakující

Tab. 5 - Entita closed

3.5 Modelování procesů pomocí diagramů aktivit Z případů užití lze vypozorovat relativně širokou škálu akcí, které je třeba analyzovat. K modelování vybraných procesů jsem zvolil diagram aktivit. Diagram aktivit rozkládá vždy jeden případ užití uvedený v kapitole 2.6 a snaží se popsat nejdůležitější aktivity postupu, který vede k úspěšnému či neúspěšnému ukončení zvoleného procesu. Při výběru případů užití, pro které jsem vypracoval diagram aktivit, jsem zohledňoval především složitost celého procesu a četnost jeho využití při práci s aplikací. Modely si kladou za cíl především přehlednost a pochopitelnost, proto jsou některé méně podstatné části procesu opomenuty nebo zjednodušeny. Při návrhu jsem postupoval podle 8.1.

3.5.1 Rezervace návštěvy klientem Jakýkoliv návštěvník stránek salónu si může rezervovat nabízené procedury, což zvyšuje šance na „nalákání“ nových klientů. Proces rezervace tedy není „schován“ jen pro registrované klienty. Zákazník si zvolí procedury, ostatní položky formuláře (personál, preferované dny a jejich části, datum od kdy do kdy má návštěva proběhnout) jsou volitelné a v případě termínu od-do jsou přednastaveny. Po odeslání požadavku se systém pokusí vyhledat vyhovující termíny. V případě jejich nenalezení bude uživatel požádán o méně striktní požadavky při dalším hledání vhodných termínů. Dalším krokem po výběru vyhovujícího termínu je identifikace žadatele. Přihlášený uživatel pouze potvrdí nabídku, registrovaný se může přihlásit, neregistrovaný registrovat či pouze zanechat kontaktní údaje. Libovolnou z operací identifikace lze provést tak, aniž by se ztratil vybraný termín rezervace. Pokud nenastane komplikace v podobě obsazení zvoleného termínu, rezervace bude uložena a zákazníkovi, pokud je registrovaný, bude odeslán potvrzující email. Diagram je zobrazen na Obr. 7.


Analýza

[Nevalidní vstupy] Vybrat procedury Vybrat personál Zobrazit formulář rezervace

Vybrat od-do data

Navrhnout termíny [OK]

Vybrat části dne

[!Návrh] Vybrat dny

Zanechat kontakt

Návrh

Registrovat se

Návrh [Vybraný]

Zobrazit summary

Vybrat termín

Přihlásit se [Registrován]

Potvrdit rezervaci

Zapsat rezervaci do databáze

[Termín obsazen]

[Přihlášen]

Personál telefonicky ověří platnost objednávky Personál je upozorněn mailem na novou rezervaci [Neregistrovaný uživatel]

Ověření uživatele

[OK] Návrh [Uložený]

Odeslat potvrzující maily

Kontrola a úprava personálem

[Registrovaný uživatel ]

Návrh [finální]

Obr. 7 - Diagram aktivity – Rezervace návštěvy klientem

Cílem této procedury není vytvořit přesnou rezervaci času, jak by ji vytvořil zkušený pracovník personálu. Problém s určení závislostí jednotlivých služeb a tedy i kombinací pořadí, ve kterém budou služby provedeny4, bude ponechán na operátorovi. Pokud systém musí rezervovat dva členy personálu, návštěva vyplní celou svou délkou pracovní čas obou členů obsluhy. Operátorovi budou přicházet maily informující o nových rezervacích. Operátor si je zobrazí a případně upraví dobu personálu tak, aby rezervovaný čas byl optimální, tj. každý člen personálu měl obsazeno přesně tolik času, kolik je potřeba na vykonání jím provozovaných služeb. Poslední věc, která patří do procesu rezervace, je ověření neregistrovaného zákazníka. Operátor ověří telefonátem, zda není objednávka smyšlená.

4 Doba, kdy bude personál pracovat zároveň ve dvojici, je značně závislá na složení zvolených procedur. Personál může spolupracovat v libovolné části návštěvy nebo naopak nejdříve bude pracovat např. kadeřník a až ukončí všechny kadeřnické procedury, bude pokračovat kosmetička.


Analýza

3.5.2 Úprava návštěvy Pravděpodobně nejdynamičtější částí systému bude formulář návštěvy. Ten má k dispozici především operátor, který díky němu tvoří, potvrzuje a edituje objednávky návštěv. Formulář musí reagovat na většinu změn načtením hodnot, které odpovídají ostatním vstupům. Tím se předchází velkému počtu neúspěšných pokusů o uložení objednávky. Se změnou data události (návštěvy) se samozřejmě mění přípustné hodnoty časů začátku a konce události (dny se mohou lišit pracovní dobou, dovolenou, obsazením jinými událostmi). Proto je třeba při změně každého vstupu, který má vliv na nabízené časy, načíst a dopočítat odpovídající hodnoty závislé na jiných „volbách“. Z diagramu na Obr. 8 je patrné, že každá změna pole formuláře je následována reakcí systému. Vstupním objektem tohoto procesu je objekt Event a výstupem je tentýž upravený objekt.

3.5.3 Diagram přeobjednání návštěvy (operátorem) Obr. 8 je součástí dále zmiňovaných diagramů a je zakreslen jako jedna aktivita. Přeobjednání návštěvy je poměrně košatý proces (viz. Obr. 9). To by mělo být velké plus pro operátora, který si může vybrat ze tří alternativ změny již vytvořené rezervace. První alternativa bude využívána v okamžicích, kdy operátor bude přesně vědět, jakou hodnotu chce změnit. Pak mu bude stačit editovat událost a změnit hodnoty. Pokud operátor nemá představu, jaký jiný termín je vhodný, může využít části procesu, která je podobná rezervaci klientem. Operátorovi se zobrazí formulář nové rezervace s vyplněnými hodnotami, které jsou načteny z původní události. Kromě úpravy již známých vstupů může operátor nastavit, jak velkou časovou mezeru hledá. Upravit event Event [upravený] [!VhodnéDatum]

Event Zobrazit event

[!VhodnýSpoluprac.] [!VhodnýČas] [!VhodnýČasSpoluprac.]

Event [upravený]

Změnit datum

Změnit hlavní personál

[!VhodnýPersonál]

[!VšeVyhovuje].

Přepočet nabízených hodnot

Změnit spolupracovníka

Změnit čas začátku

Změnit čas začátku u spolupracovníka

Obr. 8 - Diagram aktivity – Upravit event


Analýza

Systém nabídne opět několik návrhů, které si personál může prohlédnout v kalendáři. Jeden z nich může využít jako inspirační pro nalezení dostatečně velkého časového prostoru, jiný navrhovaný termín přímo zvolí. Zobrazí se mu vyplněný formulář návštěvy, který může znovu libovolně upravit. Až po potvrzení se návštěva definitivně přesune. Posledním a dle mého názoru nejelegantnějším řešením přeobjednání je využití tzv. schránky, kdy se událost uloží do paměti a operátor může listovat kalendářem či vykonávat jakoukoliv jinou činnost v systému, dokud nezvolí konkrétní neobsazenou buňku v kalendáři. Při otevření formuláře se automaticky vyplní hodnoty ze „schránky“. Opět je možné událost dále upravovat.

3.5.4 Nastavení nepřítomnosti personálu Včasné zaznamenání nepřítomnosti personálu, např. dovolené, je pro systém velmi podstatným faktorem. Je to především proto, aby v termínu nepřítomnosti personálu nebyla domluvena návštěva. Tento proces (Obr. 10) řeší i situaci, kdy již je někdo objednán. Tato situace může být např. zaviněna onemocněním. Pokud nastane konflikt termínu dovolené a objednaných návštěv, systém jej zobrazí. Zaměstnanec může konflikt odstranit přeobjednáním kolidující návštěvy. Druhou možností je nechat systém navrhnout nový nekonfliktní termín návštěvy. [Neuloženo] Event [Upravený]

Upravit event

Uložit event

Detailně rozebráno výše

Event [Původní]

[VímDélku]

Zobrazit event

Zobrazit formulář pro přeobjednání

Zvolit min. dobu trvání hledaného volna

Změnit procedury Změnit personál Kopírovat do schránky Vybráním termínu z kalendáře se může změnit datum, personál a čas eventu

Načíst preferované hodnoty

Změnit data Změnit části dne

Zvolit termín V kalendáři

Event [Upravený]

Zobrazením se personál ujistí, že systém nemohl v daný den navrhnout lépe vyhovující časy

[Nahlédnout]

Návrh [Zvolený]

Zvolit návrh

Změnit dny

Zobrazit návrhy v kalendáři

Návrhy

Obr. 9 - Diagram aktivity – Přeobjednání návštěvy


Navrhnout termíny

Analýza

[!NovýKonflikt]

Zkontrolovat plán práce ve zvolených dnech

Přidat volno [!PracovníDen]

[OK]

[Uloženo] Uložit volno

[JeKonflikt ]

[!Uloženo] Zobrazit kolize

Event

[!JeKonflikt]

Přeobjednat [JeKonflikt]

Navrhnout přesuny kolizních events

[VhodnéŘešení] Zvolit návrh

Event

Přeobjednat

[!Uloženo]

[!VhodneŘešeni]

Obr. 10 - Diagram aktivity – Nastavení nepřítomnosti personálu

Nový návrh lze před potvrzením editovat.5

3.6 Stručný úvod do požadovaných technologií V samotném zadání této práce jsou definovány dvě konkrétní technologie, které se k vývoji mají použít. Jedná se o rámec Struts a Ajax technologii.

3.6.1 Jakarta Struts Rámec Struts je v porovnáním s technologií Ajax starší6. Vytvořil jej Craig R. McClanahan a v roce 2000 rámec uvolnil k volnému šíření, což vedlo ke značnému rozšíření funkčnosti i použitelnosti rámce. Vývoj se nezastavil a v roce 2007 byly uvolněny další verze (1.3.8, dokonce 2.0.6). O oblibě svědčí i rozšiřující knihovny, např. Struts Layout nebo Ajax Anywhere.

Technologie JSP K snazšímu pochopení Struts se v krátkosti zmíním o Java Server Pages, k čemuž využiji citace z [1]. „Nejprve je nutno uvést, že JSP je přirozeném rozšířením technologie Java Servlet. V podstatě lze říci, že po jistých úpravách pomocí překladače se z JSP stávají obyčejné Java Servlety. JSP jsou textové dokumenty s příponou .jsp obsahující kombinaci statických HTML 5

Protože jsou návštěvy objednány na určitou hodinu, lze změnit pouze personál. V případě nutnosti změny i času či data je nutné klienta telefonicky kontaktovat. Proto systém hledá varianty přesunu pouze v rámci změny personálu. 6 Teoreticky byl základ Ajaxu položen již v roce 1999 (objevuje se objekt XMLHttpRequest), ale hojně se začal používat až po roce 2004.


Analýza

tagů, tagů ve stylu XML a scripletů. Tagy a scriplety zapouzdřují logiku tvorby obsahu stánek. Soubory .jsp se předem zpracují a převedou na soubory s příponou .java. A v tom okamžiku kompilátor Javy zkompiluje zdrojový kód a vytvoří .class soubor, který může být spuštěn kontejnerem servetů.“ Rámec Struts pracuje na podobném principu, jen využívá větší množiny vlastních značek a je postaven na návrhovém vzoru Model-View, Controller (MVC) viz Obr. 11. Protože stejné výhody jako JSP má díky shodnému principu překladu na výsledné .class soubory i Struts (nehledě na to, že pokud bychom ve Struts psali čistě JSP stránky bez využití knihovny tagů pro Struts, funkčnost by zůstala zachována), byla by škoda se o nich nezmínit. JSP je specifikace, nikoliv produkt. JSP stánky sdílejí charakteristiku Write Once, Run Anywhere technologie Java. JSP stránky podporují jak skriptování, tak přístup k plnohodnotné Javě a lze je rozšířit použitím uživatelských tagů.

Model-View-Controller ve Struts Model zodpovídá za správu stavu vnitřní struktury Model může nabývat více podob v závislosti na typu aplikace. U dvouvrstvých aplikací typu web – databáze může být např. reprezentován množinou Java objektů, které jsou ručně nebo pomocí mapování souvisejících objektů (ORM) naplněny daty. Ve složitějších případech je reprezentován např. Enterprise Java beany. Lze říci, že modelu předáme konkrétní vstupy (které získáme z pohledu) a očekáváme výstupy bez dodatečného propojení modelu s Controllerem či View. Model by měl být nezávislý na prezentační vrstvě. Dává logiku hrubým datům, např. vstupnímu datu, získanému z pohledu, přiřadí, kdo má v tento den jmeniny. Model se nezabývá tím, jak datum získat z pohledu. Pohled zodpovídá za vnější prezentaci vnitřní struktury. View vrstva je tvořena komponentami typu: HTML, JSP značky, uživatelskými značkami, formuláři (zde je formulářem myšlena třída ActionForm, která slouží k předávání dat mezi klientem a business vrstvou). HTML stránky slouží k zobrazení statického obsahu, zatímco JSP slouží k zobrazení dynamického obsahu. Většina dynamického obsahu stránek je generována ve webové vrstvě, která je zodpovědná za prezentaci business dat. View je vše, co slouží k zobrazení výsledné stránky (to co ovlivní vygenerování výsledného HTML kódu). Řadič odpovídá za kontrolu průběhu a stavu uživatelského vstupu. Controller (ActionServlet) zachycuje požadavky od klienta a překládá je na business operace, nebo tyto operace přímo vykonává. Pomáhá s výběrem další stránky a vrací ji klientskému prohlížeči jako odpověď na jeho požadavek. Je zodpovědný za řízení a stav vstupu od klientské strany. Vývoj ve Struts vyžaduje dodržení rámce a využití správných knihoven. Odměnou je vytvoření aplikace s MVC modelem a všemi jeho výhodami. Daní, kterou platíme za získání relativně jednoduchého nástroje pro definování stránek (díky knihovnám značek), snadnou validaci a přehledné směrování uživatele mezi akcemi a stránkami, je povinnost použití a překrytí tříd knihoven Struts, komplikovanější rozšiřitelnost těchto knihoven, poněkud nedostatečná dokumentace (ve srovnáním s Javou) a chabé chybové hlášení.


Analýza

Obr. 11 – Model-View-Controller (View zde dolní část obdélníku), převzato z 8.2

K pochopení složitosti Struts uvedeme stručně, jaké kroky jsou třeba k tomu, aby byl vyplněný HTML formulář odeslán a zpracován. Je potřeba provést: Pro controller – definovat akci, která se vykoná po odeslání formuláře, přiřadit konkrétní Action a ActionForm, doplnit možné směrování z Action (minimálně při úspěchu a neúspěchu), nastavit pole, která se mají validovat. Implementovat samotnou třídu Action. Pro pohled – napsat ActionForm7, tedy definovat všechny proměnné, které budeme přenášet na stránku a zpět ze stránky, napsat pomocí knihoven značek vlastní stránku, napsat objekty pro transport dat pro model, který bude tuto akci zpracovávat. Napsat nejlépe obecný model, který provede logickou část aplikace, např. uložení hodnot do databáze. Předpokladem jsou správně nakonfigurované „properties“ soubory. Z popisu je zřejmé, že se Struts nehodí pro aplikace malého rozsahu, protože nakonfigurování toho, aby správně fungoval zejména controller, je časově náročné. Naopak, pro středně velké aplikace se investovaný čas vrátí. Získáme relativní přehled o toku dat, máme zajištěno, že controller kontroluje práva uživatele na provedení zvolené akce, s velkou pravděpodobností využijeme napsané ActionFormy a Beany vícekrát, máme relativně zadarmo zajištěnou podporu více jazyků a jednoduchou úpravu layoutu stránek.

3.6.2 Technologie AJAX Původní webové stránky byly statické - uživatel požádal o zdroj a server mu ho odeslal. Dalším krokem byla interakce založená na vstupech formulářů, dynamickém vyhodnocení požadavků a odeslání informací, které byly determinovány vstupy. Veškeré výpočty byly provedeny na serveru a v prohlížeči stránka vypadala jako statický dokument. Operací, které měl server vykonat, přibývalo, zatímco rychlost internetu se zvyšovala jen pomalu. Některé dotazy na server byly přitom velmi jednoduché a velikost odpovědi vzhledem k velikosti hlavičky stránky byla zanedbatelná – mnoho přenášených dat bylo pro uživatele „zbytečných“. 7

V pozdějších verzích je možné využít dynamických formulářů a jiných vylepšení, aby bylo redukováno množství nutného kódu.


Analýza

Prvním řešením byly Java Aplety. Jejich nespornou výhodou byla podpora knihoven Javy, nevýhodou byla nutnost instalace JRE na klientské stanici a opět k některým jednodušším požadavkům zbytečně velký přenos informací ze serveru. JavaScript byl původně vytvořen, aby pomohl serveru řešit určitou část logiky na klientské straně. Zpočátku bylo této vlastnosti využito především pro úpravu vzhledu stránek (CSS). Díky DOM8 se vývojáři začali na stránku dívat jako na objekt, který může být modifikovaný pomocí skriptovacích jazyků jako je JavaScript nebo VBScript. Stačilo už jen počkat, až výrobci prohlížečů zahrnou podporu JavaScriptu do svých produktů. Nejčastěji se JavaScript uplatnil při validaci vstupů formulářů a při operacích měnící pouze část stránky (rolovací menu). Data, která k tomu JavaScript využíval, obdržel od serveru při doručení odpovědi. Posledním krokem k zavedení technologie založené na JavaScriptu, byl impuls především společnosti Google9, která světu ukázala, jak se dá využít spolupráce serveru a JavaScriptu tak, aby výsledek zvyšoval uživatelský komfort a v některých případech i snižoval přenos dat po síti. Ajax je spíše technika než specifická technologie a JavaScript je jeho hlavní komponentou. Jednoduše řečeno, AJAX funguje následujícím způsobem. Akce uživatele spustí funkci JavaScriptu, která odešle připravené informace na server (Ajax je schopen komunikovat s většinou serverových technologií). Zde jsou vstupy zpracovány, jako by se jednalo o klasický požadavek, ovšem odpovědí serveru není kompletní stránka, ale jen ta část, která nás zajímá. Při odeslání požadavku byla stanovena funkce, která zpracuje odpověď serveru a případně změní část stránky. K pochopení může posloužit Obr. 12. Hlavní nevýhodou Ajaxu je nemožnost plného využití tlačítek prohlížečů Zpět a Vpřed. Další může být velká prodleva mezi požadavkem a odezvou. Chybou bývá využití Ajaxu tam, kde by stačil JavaScript, v okamžiku, kdy je načítána většina stránky, a také tam, kde jsou příliš časté automatické požadavky na server, které zbytečně zatěžují síť. Pro informaci uvedu několik příkladů využití Ajaxu. Obecně se jedná o „dočítání“ hodnot, které jsou závislé na daných vstupech (při vyplňování adresy se zadáním státu se omezí výběr měst). Velké oblibě se těší tzv. našeptávač, který na základě shody prvních znaků dohledává v databázi možné textové řetězce, které by uživatel mohl použít k automatickému dokončení vstupu. Mezi komplikovanější využití patří např. posun zobrazené mapy. Dříve bylo třeba poklepat na odkaz „vpravo“, aby se náhled na mapu posunul. Další zajímavé využití je při komplikovaných dotazech, kdy stránka je postupně doplňována o nalezené výsledky. Nemusíme čekat, až skončí celý proces hledání, a můžeme studovat prozatímní výsledky. V této kapitole bylo čerpáno z 8.1.

8

Dokument Object Model Ještě před rokem 2000 Microsoft navrhl objekt XMLHttpRequest a Internet Explorer verze 5 jej podporovala. Microsoft tohoto objektu využil v Outlook Web Access podporovaném Microsoft Exchange Server 2000. Ajax v té době nezbudil takovou pozornost, proto až druhá vlna využití Ajaxu byla díky Google úspěšnější. Více o historii 8.2. 9


Analýza

Obr. 12- Schéma fungování technologie Ajax, převzato z

3.7 Závěrem k analýze Dle mého mínění je problematika dostatečně popsána a analyzována. Samozřejmě nebyly rozebrány všechny situace a jejich procesy. Jen diagramů aktivit by mělo být stejně jako je případů použití, ovšem jejich přínos by nebyl nikterak převratný. Veškeré editace, ze kterých se především odvíjí nepopsané případy použití, jsou složeny z těchto kroků: načtení hodnot, úprava, odeslání, validace, úprava dat, uložení a potvrzení vložení či neúspěchu. V kapitole 3.3.7 byla velmi podrobně popsána datová analýza. V části kapitoly (3.2) byly zmíněny požadavky na hardwarové a softwarové vybavení nutné k bezproblémovému chodu systému. V posledních podkapitole (3.6) jsem jednoduše naznačil funkčnost technologií, které budou využity k implementaci.


Návrh

4 Návrh Výsledný systém bude implementován nad rámcem Jakarta Struts, který je postaven na jazyku Java. Jednotlivé třídy Javy se nejen pro přehlednost, ale i pro určení souvislosti seskupují do tzv. balíků (package). Třídy v balíku jsou si blíž umístěním a lze uplatnit viditelnost metod a proměnných v jednom balíku. Při návrhu komponent by měly být vzaty v úvahu tyto vlastnosti javovských balíků. Na druhou stranu není vždy výhodné rozdělovat třídy do balíků Javy podle návrhu komponent. Jako příklad mohou sloužit třídy odvozené od společného přímého předka, které je vhodné umístit do jednoho balíčku, ale v návrhu komponent, v nichž klademe důraz především na návrh funkcionality, je pro přehlednost využití více komponent výhodou. Při návrhu jednotlivých komponent jsme se zaměřili na akční třídy rámce Struts a k nim neodmyslitelně patřící třídy formulářů. Pro související akce a formuláře jsme určili komponentu návrhu. Rámec Struts vyžaduje využití svých tříd ve většině komponent systému. Aby byla zachována přehlednost návrhu, zmíním se jen o nejpodstatnějších třídách tohoto rámce. V globálním pohledu na balíčky návrhu (na Obr. 13) lze rozpoznat balík, na který bude kladen největší důraz. Jedná se o ActionPackage, umístěnou ve středu. Všechny třídy v tomto balíku jsou potomky org.apache.struts.action.Action. V nich se zpracovávají Server <> Tools

Utils

<>

Databáze

<>

SMTP server

ActionPackage

<>

<>

BeanPackage

<>

Server rutines

FormPackage

Obr. 13 – Vazby mezi navrženými balíky


Services

Návrh

požadavky odeslané z klientské části aplikace, přebírají se parametry požadavků, určuje se, jaký model bude využit pro provedení logické části požadavku a určí se výsledné směrování odpovědi. Další povinnou částí Struts jsou formuláře, které dědí nejčastěji od org.apache.struts.action.ActionForm nebo org.apache.struts.validator.ValidatorForm.

Na diagramu jsou znázorněny i komponenty Databáze a SMTP serveru, které jsou propojeny se systémem v jednom místě, a proto by neměl být problém přechod na jinou databázi či SMTP server. Tento návrh byl proveden ještě před podrobným seznámením se s technikou programování ve Struts. Pokud bych se měl dnes zamyslet, pravděpodobně bych udělal několik změn. Především bych rozdělil package na více úrovní, asi bych nerozděloval spolu související akční třídy a formuláře. Jedná se jen o kosmetické úpravy, které lze provést i v pokročilé fázi vývoje, ale z důvodů velké pravděpodobnosti chyby v controlleru (nastavuje se v strutsconfig.xml) jsem se k nim zatím neodhodlal.

4.1 Popis základního návrhu jednotlivých komponent Nejdříve se zmíním o balíku utils, který lze rozdělit na čtyři podsekce, jak je patrno z Obr. 14.

utils

DbAcces

Mai

SortDefinitions

DateTime

Obr. 14 –Balík utils

DbAccess zapouzdřuje třídy, které jsou nutné k připojení k databázi, sestavování dotazů a jejich provádění. Mail obsahuje jedinou třídu stejného jména, která řeší odesílání emailů ze systému. V SortDefinitions jsou utility implementující interface Comparator a jsou využity k řazení, které aplikují třídy diáře. Balík DateTime je zužitkován při operacích s časovými údaji. Mezi nejpoužívanější patří převody mezi jednotlivými národními nastaveními a především veškeré převody vstupů (nejčastěji Stringů) na správný čas či datum. Podrobněji se budeme věnovat dvěma třídám – Mail a MySQL.


Návrh

MySQL

Mail

-con : Connection -stmt : Statement -rs : ResultSet -dataSource : DataSource +isConnect () : boolean +connect () : boolean +execSQL (String ) : ResultSet +updateSQL (String ) : int +close()

-message : String +postMail (...) +sendReminderMail +createMessageNewE (...):String +createMessageNewByPers (…):String +createMessageDeleted (...):String +createRegistration (...):String +createReminder (...): String -addServicesNames ():ArrayList

Obr. 15 –Návrh tříd MySQL a Mail

MySQL bude využita ke komunikaci jednotlivých tříd s databází. Spojení bude založeno na základě dataSource získaného z requestu10. DataSource je podrobně nastaveno v konfiguračních souborech Struts a lze jej relativně snadno modifikovat. Při vytvoření instance této třídy se ihned vytvoří spojení, které je vždy před jeho použitím kontrolováno a případně obnoveno. Aplikaci třídy lze shrnout takto: Objekt, který se chce připojit k databázi na základě requestu, založí instanci třídy MySQL, využívá ji dále k dotazům do databáze a v situaci, kdy již spojení nepotřebuje, se od databáze odpojí. Třída Mail se aplikuje v situacích, kdy má být odeslán mail. Tělo vlastní zprávy může být generování v metodách k dané situaci určeným. Návrh tříd Mail a MySQL včetně metod a globálních proměnných je na Obr. 15.

4.1.1 ActionPackage Jak již bylo uvedeno, to nejdůležitější, co se logiky programu týče, se odehrává v potomcích třídy Action. Zde je vždy nutno překrýt metodu execute(…). Vstupy této metody jsou instance HttpResponse a HttpRequest. V jejich úvodu se získávají data z odeslaného formuláře do prostředí instance akce. V závěru se připravují data k zobrazení na další stránce, která je vybrána na základě požadavků. Hlavní podskupiny balíku ActionPackage jsou znázorněny na Obr. 16.

ActionPackage

ServicesActions

TimeActions

LogonActions

Reservation Actions

UserActions

OverviewActions

StatisticActions

DiaryActions

PersonalSett ingsAction

Obr. 16 – Balíky vnořené do ActionPackage

10

V verzi Struts 1.3.5 je získávání datasource z requestu zakázáno. Pokud by se v budoucnu mělo přejít na novější verzi Struts, využije se k připojení třídy Db, která má stejné metody, jako MySql, ale připojení získává z konfiguračních souborů vlastního serveru.


Návrh

Nejsprávnější aplikace akční třídy by měla získat vstupy, odeslat je jiným, na Struts nezávislým částem podsystému (modelu). Model by připravil data a opět je předal do Action a ta je připravila pro zobrazení na příslušné stránce11. Kostra všech balíčků s akčními třídami je stejná. Jedna akce připravuje stránku pro zobrazení, další z ní na základě zvolené akce uloží (případně změní) data v databázi. Občas nastane situace, že jedna akční třída je následována druhou. Takové zřetězení může být užitečné, například když akce provede nějakou operaci s daty, ale sama nepřipravuje odpověď, která bude zobrazena. Pak je vhodné zavolat třídu, která data pro zobrazení připraví. PersonalBusy -workingTimeMinutes : long -workingTime : long[7] -workedTimeMinutes : long -holiadyTimeMinutes : long -weeks : int -utilization : double -db : MySQL -setWorkingTime ():long -setWorkedTime ():long -setHolidayTime ():long -countUtilization ():double +countAvail ():long +savePriority ():int

EventAction +execute () :ActionForward -fillCoworker () :NewEventForm +biggerThan () :Collection +setStartSelect () :Collection +setEndSelect () :Collection -setTimesPersonal () :String[] -fillCoworkers () :Collection -fillPersonal () :Collection -fillServices () :NewEventForm -setStartFrom () :String -setEnds () :String +removeEventClickedIn () :Object [] +makeLabelValueBean (): Collection +freeTime () :Object [] +removeAllAfter () :Collection +getOnlyBetween :Collection

Obr. 17 –Návrh tříd PersonalBusy a EventAction

Nevýhodou akčních tříd je, že je nelze využít jako plnohodnotné nestatické objekty, protože rámec Struts vytvoří v aplikaci každou instanci jen jednou a ta existuje po celou dobu běhu aplikace (přitom není statická). To omezuje např. v použití globálních proměnných, které by nabývaly pro různé uživatele stejných hodnot. Třída EventAction má za úkol připravit hodnoty formuláře návštěvy. Část metod je využívána i třídou SaveEventAction, proto jsou veřejné. Pravděpodobně již z názvu metod lze určit, že se jedná o metody plnící např. možnosti výběru u značky select. Tato třída je využita i při zobrazování již zadané návštěvy, a proto se zbylé metody zabývají nastavením hodnot konkrétní návštěvy. Posledním návrhem třídy je „logická“ třída, tedy třída reprezentující vnitřní logiku problému. Na Obr. 17 navržená třída PersonalBusy bude počítat vytíženost personálu. Přetížený konstruktor a metody dovolí poměrně jednoduchým voláním spočítat ve specifikovaném datovém rozpětí časy dovolené, práce a pracovních hodin, které se v metodě countUtilization() poslouží k výpočtu hledané statistiky. Třída PersonalBusy byla navržena mezi posledními, a proto jako jedna z mála splňuje požadavek nezávislosti výpočtu na Struts. Většina modelů byla však navržena dříve, tudíž je centrem jejich logické části akční třída. Package Services bude existovat mimo hlavní projekt, protože bude na serveru umístěna jako Service ARchive' (SAR). Jedná se o třídy odvozené od 11 O tomto postupu jsem se dozvěděl až krátce před dokončením projektu, a tak v původním návrhu a implementaci nebyl použit.


Návrh

které lze na serveru JBOSS poměrně jednoduše řídit a plánovaně opakovaně spouštět. Service Archive běží ve vlastní vrstvě na serveru – The JBoss Service Layer, zbylá část aplikace je spouštěna z aplikační vrstvy. Balík Services využívá package Utils (třídy Mail a Db) a Tools (třídy nutné k výpočtu statistik) z hlavní aplikace. Služba SalonService se bude starat o zasílání upozorňovacích mailů o návštěvě. SalonStatService bude přepočítávat vytížení personálu, na jehož základě se přiděluje personál. org.jboss.system.ServiceMBeanSupport,

4.2 Návrh mapy stránek Osoby, které budou přistupovat k www stránkám tohoto projektu, lze rozdělit do dvou skupin: klienti a zaměstnanci salónu. Na klienty nesmí stránky a pohyb mezi nimi působit komplikovaně, měli by mít přehled o tom, kde se nachází. Nebudou tedy očekávat pravděpodobně by toho ani nevyužili – širokou škálu nastavitelných parametrů. Domnívám se, že jednoduchost a přímočarost ve spojení s minimálním množstvím aktivních prvků (odkazů) bude splňovat požadavky na snadnost ovládání. Jak je na Obr. 18 vidět, největší hloubka stránky je tři, a to pouze v případě rezervace. Jestliže je u jména stránky obrázek formuláře, značí to, že je třeba očekávat od uživatele aktivitu v podobě zadání vstupů. Pokud je to možné, zobrazí se výsledek požadavku na stejné stránce, aby měl uživatel pocit, že se pohybuje ve známém prostředí. Čárkovaně je vyznačena cesta, která je pouze jednou z alternativ. Přehlednost zvýší i menu, které bude po celou dobu na stejném místě. Pro zaměstnance budou stránky v podobném duchu, tedy minimálně vnořované, změny budou potvrzeny na stejné stránce. Výjimkou v návrhu bude skrývání grafické hlavičky a menu na stránkách kalendáře, resp. na stránkách otevřených v menším okně. Ty potřebují maximální prostor na obrazovce pro přehledné zobrazení více dnů kalendáře pro personál. Otevřené okno by mělo co nejméně zabraňovat pohledu na okna pod ním (viz Obr. 31).

Registrace

Rezervace 1/3

Rezervace 2/3

Rezervace 3/3

Vlastní objednávky Detaily uživatele

Obr. 18 – Mapa stránek uživatele


Dokončená rezervace

Návrh

Volba dovolené

Diář

Hledání Volna

Konflikty dovolené

Editace eventu

Sumář eventu

Hledání Volna 2

Obr. 19 – Mapa vybraných stránek pro personál

Návrh mapy zaměstnanců (Obr. 19) jsem redukoval jen na případy, kdy se vnořuje více stránek. Vše se děje poblíž diáře. Hlavní osu tvoří zadávání a editace návštěv. V diáři je zvolen čas, ve kterém již návštěva je, nebo jej sem chceme vložit. Zobrazí se formulář návštěvy, který velkou část informací načítá v průběhu úpravy jednotlivých vstupů. Krátce se zdržím u návrhu identifikace volajícího zákazníka. Pokud operátor přijme hovor klienta, který se chce objednat, vybere vyhovující termín a úkony. Dále je potřeba identifikovat osobu, která si návštěvu rezervuje. Systém bude podporovat dohledávání jmen v databázi všech neregistrovaných i registrovaných návštěvníků a v případě shody znaků příjmení napoví celé jméno. Problém shody jmen budeme u registrovaných uživatelů řešit doplněním přihlašovacího jména za jméno a příjmení. U neregistrovaných uživatelů udržujeme jen příjmení a telefonní číslo. Zde již identifikace nemusí na rozdíl od registrovaného uživatele nalézt jedinečný záznam jmen, a proto se rozhodne podle telefonního kontaktu. Tato část identifikace především registrovaného zákazníka je velmi důležitá z hlediska uživatele. Ten se později může přihlásit do systému a telefonicky domluvenou schůzku může upravit či zrušit. Nyní je uživatel identifikován, jeho návštěva je vytvořená a operátor může potvrdit volajícímu termín i všechny podrobnosti návštěvy, které se zobrazí na stránce Sumář návštěvy. Pokud bude provedena operace, která je nebezpečná, např. odstranění spolupracovníka, který klienta obsluhoval, bude operátor upozorněn na vzniklou situaci a dotázán na další postup. S kalendářem jsou provázány další dvě činnosti. Při rezervování dovolené jsou zobrazeny konfliktní návštěvy (pokud existují) a uživatel si může nechat znázornit přímo ve formuláři návštěv detail návštěvy. Při nabídce řešení si může nechat zobrazit celkový pohled na den personálu, který by měl návštěvu převzít. Pokud bude operátor hledat prostor pro novou návštěvu, využije prvního kroku rezervace, který budou využívat klienti. Druhý krok této rezervace však navíc nabízí pohled do kalendáře zaměstnanců, kteří byli vybráni k obsluze právě vznikající návštěvy. Operátor tak může


Návrh

upravit rozhodnutí programu a vylepšit termín díky vizuálnímu přehledu situace. Pokud termín bude vyhovovat, automaticky se vyplní formulář návštěvy hodnotami zadanými v prvním kroku rezervace a operátor již pokračuje stejně, jako by editoval návštěvu.

4.3 Návrh uživatelského rozhraní Návrh uživatelského rozhraní nesmí být podceněn. Veškerá komunikace uživatele se systémem probíhá přes jednotné a nejlépe i přehledné, srozumitelné, interaktivní rozhraní. Úspěšnost celého projektu závisí na výsledném využívání stránek. Uživatel se rozhodne na základě několika málo sekund, zda mu stránka nabídne to, co hledá. To, co nevidí, jej nemůže zaujmout. Tato práce si klade za cíl propracovat ono pozadí projektu (lze pouze vytušit z nabízené funkcionality) s tím, že vše bude připraveno k přepracování výsledného vzhledu aplikace. To, že návrh systémů jasně odděluje vzhled stránek od jejich vnitřní aplikační logiky, značně ulehčuje změny designu. Velmi pravděpodobné je, že i kdyby současný návrh byl dostačující, za určitou dobu se přestane líbit, a proto musí být vzhled modifikovatelný bez větší znalosti systému.

4.3.1 Vzhled K tomu, aby byl vzhled modifikovatelný, je výhodné použít šablony. Bylo již naznačeno, že budou implementovány šablona pro uživatele a šablona pro speciální stánky zaměstnance. Hlavní šablona by měla uživatele upozornit, o jaké stránky se jedná. Lidé, kteří navštěvují kadeřnický salón, nebudou s velkou pravděpodobností svůj zevnějšek svěřovat do rukou salónu s nevýrazným, nezajímavým vzhledem www stránek.

Obr. 20 – Návrh vzhledu stránky


Návrh

Obr. 21 – Návrh speciálních stránek

Návrh počítá s grafickým prvkem (pravděpodobně technologie Macromedia Flash) v horní třetině stránky. Menu by nemělo být skrývané, protože odkazy by nemusely být nalezeny. Šablona, která bude použita k vývoji a testování, je zobrazena na Obr. 20 – Návrh vzhledu stránky. Je rozdělena do čtyř částí, záhlaví a zápatí bude téměř statické, část menu a těla stránky bude záviset na stavu aplikace. Druhá šablona znázorněná na Obr. 21, používaná především při zobrazení kalendáře, je účelná. Nabízí několik rychlých voleb a stav uživatele zobrazený v úzkém pruhu v horní části stránky. Zbytek plochy je volný kvůli pohodlnému zobrazení kalendáře. Návrh kalendáře (Obr. 22) je přímo ovlivněn požadavkem na velkou podobnost s doposud používaným. Tabulka bude definována HTML kódem. Jedna návštěva u jednoho zaměstnance bude vždy jedna buňka a její velikost bude odpovídat době trvání. V kalendáři se zobrazí i pracovní doba a dovolená. Všechna zbývající pole značí, že jsou volná a lze je zaplnit další návštěvou.

4.3.2 Šablony Výše zmíněné šablony budou implementovány pomocí jedné z knihoven značek Struts – Tiles. Návrh vzhledu bude centralizován v šabloně, do které se budou vkládat jsp stránky. Teprve takto složená stránka se přeloží na HTML značky. Každé stránce se přiřadí, do které šablony i na jaké místo v ní bude vložena. Navíc každá stránka může vystupovat pod více „jmény“, Kadeřník Kadeřník2 Kosmetička Pedikúra Manikúra Kadeřník Kadeřník2 Kosmetička Pedikúra 28.X. 28.X. 28.X. 28.X. 28.X. 29.X. 29.X. 29.X. 29.X. 9:30 Nepracuje Růžičková 10:00 Doležal Růžičková Kačerová Dovolená 10:30 Husáková Doležal Koperník 11:00 Nepracuje Kačerová 11:30 12:00 Obr. 22 –Návrh kalendáře


Návrh

takže konfigurace Struts a příslušné mapování již v Action Strus určí, jakou šablonu stránka využije ke svému zobrazení.

4.3.3 Podpora více jazyků Vzhled stránek může být sebelepší, ale pokud jim zákazník nebude rozumět, s velkou pravděpodobností je ihned opustí. Vícejazyčná podpora je řešena pomocí RessourceBundles. Jedná se o velmi rozumnou techniku shromažďování veškerého psaného textu, který je zobrazen uživateli, na jednom místě. Do programu se jednoduše řečeno vkládají odkazy do těchto souborů a při vykreslení stránky se tyto odkazy nahradí textem ve zvoleném jazyce. Protože se při rezervacích pracuje s daty, je nutné je převádět do správného formátu, tedy v českém prostředí je nejdříve zobrazen den, následně měsíc. V anglicky mluvících zemích je na prvním místě měsíc. Sestavení řetězce data se děje v akčních třídách a je potřeba každé datum, které se přijímá ze stránek či se na ně odesílá, přečíst nebo zapsat ve správném lokálním formátu. Navíc kalendáře, které usnadňují výběr data, je potřeba s lokálním nastavením svázat také. Hlavní rozdíl je v zobrazování dnů v týdnu (neděle nebo pondělí na prvním místě). K tomuto bude využito knihovny značek Struts-Layout, která již není standardem Struts. Jedná se o rozšíření vyvíjené jinou skupinou než Struts.

4.3.4 Důležité detaily uživatelského rozhraní Na první pohled neviditelné, ovšem často využívané, jsou tzv. tooltipy, tedy nápověda, která se zobrazí po přidržení myši nad objektem. Výhodou těchto skrývaných informací je, že stránku nekomplikují a zobrazí se, až je potřeba. V první verzi této práce se využije pouze textových nápověd, ale myslím si, že pokud by se využila technologie Ajax a byly by dočítány i obrázky, mohlo by to zvýšit uživatelský komfort. Uplatnění obrázků s textem by bylo např. vhodné při volbě jednotlivých procedur, případně při volbě personálu. Stránkování a řazení výběrů je dnes při zobrazování většího množství dat nutností. Využijeme opět knihoven Struts-Layout, které danou problematiku řeší. Ajax bude na stránkách využit prozatím jen v sekci pro personál, nicméně zde by měl velmi usnadnit práci. Především se jedná o našeptávání u jmen, kterého s výhodou použijeme Struts Layout (v prvních verzích jsem jej implementoval sám, v Struts-Layout se jedná o přehlednější řešení). Struts-Layout bude využit ještě v jedné situaci, která by měla napomoci větší přehlednosti. Případné dotazy systému nebudou muset být prováděny pomocí JavaScriptových hlášek, ale využitím vrstev stránky. Pozadí zůstane zobrazeno, ale bude překryto vrstvou, která znemožní pokračování. Aktivní na této vrstvě budou jen tlačítka odpovědi na položenou otázku. Protože se jedná o poněkud méně využívanou techniku, pracujeme s ní pouze v jedné situaci. Po testech použitelnosti se potom rozhodne o jejím dalším využití. Knihovna Ajax Anywhere usnadní dočítání platných hodnot na formuláři návštěvy. Zde se jedná také o uživatelsky velmi příjemnou věc, protože nemůže dojít k chybnému zadání dvojice začátku a konce návštěvy. To samé se týká nabídky dat pro případného spolupracujícího zaměstnance. On-line rezervační systém 40

Návrh

V neposlední řadě se jedná o řešení chybových hlášek. Vstupy, jejichž správnost lze kontrolovat již na straně klienta, se zde zkontrolují a všechny chyby se zobrazí na stránce zároveň. Druhotná validace probíhá na serveru a případná chybová hlášení se zobrazí výrazným fontem v horní části formuláře. Nejlepším řešením bude zvýraznění chybně zadaných vstupů přímo na stránce, s tím se počítá především v registračním formuláři.

4.4 Akceptační testy a testy použitelnosti Pro úspěšné dokončení testu musí být projekt akceptován. Akceptací zákazník potvrzuje, že jsou splněny všechny jeho požadavky, které byly shrnuty v kapitole 2. Akceptační testy bude provádět osoba, která se nepodílela na vývoji tím, že bude postupovat podle vytvořeného scénáře. Tyto testy se budou provádět přímo před autorem, který bude konzultovat případné nedostatky a zaznamenávat si nutné změny. Ihned po dokončení požadavku vyplní testující osoba příslušný akceptační formulář (příklad je uveden v Příloze 8.2). Velkou roli hrají akceptační testy prováděné přímo zaměstnancem společnosti, které projekt zadala. Nejen v této fázi, ale i v dalším životě softwaru bude potřeba testové výsledky shromažďovat. Kromě výpisu, který program provádí do souborů na serveru, je potřeba připravit na programu nezávislou jednoduchou aplikaci, které uživatel bude moci hlásit chybu a popsat, co jí předcházelo. Předávání výsledků testů bude zajištěno tím, že aplikace pro hlášení chyb bude umístěna na serveru, k němuž budou mít přístup i autoři Salónu.

4.4.1 Testy použitelnosti Ve fázi, kdy je projekt (případně jen jeho část) relativně stabilní, avšak ne nutně dokončený, se doporučuje provést testy použitelnosti. V případě této aplikace se jedná především o testování logického uspořádání GUI a ovladatelnosti. Lze předpokládat, že teprve tyto testy stanoví konečné pořadí polí na jednotlivých formulářích. Další výsledky testování, především rezervace a ovládání kalendáře, mohou znatelně promluvit do skladby jednotlivých prvků na stránce, jejich názvů. To se týká nejen menu, ale třeba i pořadí sloupců v tabulkových výpisech. Výhodou odděleného návrhu aplikace od vnitřní logiky je, že případný neúspěch v testech použitelnosti lze zásadně opravit změnou celkového vzhledu aplikace. V kapitole 6.4.1 byly je popsán test použitelnosti procesu rezervace.


Implementace

5 Implementace Zkušenosti softwarových inženýrů praví, že implementační část je jednoduchá, pokud byla vytvořena bezchybná analýza a návrh. Dle mého názoru je předpoklad těžko splnitelný. Naše analýza a návrh na druhou stranu nechala některé implentační části na kreativitě autorů zdrojového kódu.

5.1 Použité technologie a nástroje 5.1.1 Volba technologií V kapitole 3.6 jsem stručně uvedl technologie Struts i Ajax, nyní se zejména Struts budu věnovat podrobněji. V kapitole 3.2.1 jsem krátce zdůvodnil volbu použitých serverů – aplikačního (JBoss 4.0) i databázového (MySQL 5.0).

5.1.2 Volba nástrojů Projektem Salónu se zabývám již od podzimu roku 2005 (viz. kapitola 2.7). Během téměř dvou let jsem vystřídal několik vývojových prostředí. Z počátku jsme se potýkali s velkými problémy vůbec spojit vývojové prostředí se serverem tak, aby bylo možné přeložený kód umístit při překladu rovnou na server. Prvním vývojovým prostředím pro Javu i jsp byla Eclipse 3.0. Výhodou tohoto prostředí je značné množství rozšiřujících balíčků, jen orientace v nich není příliš přehledná. Právě proto jsme pravděpodobně nenašel rozšíření, které by podporovalo nápovědu knihovny značek Struts nebo ještě lépe syntaxi (a když už jsme vhodné rozšíření MyEclipse našel, jednalo se o komerční produkt). Obrovskou nevýhodou byla nemožnost ladění kódu. Ve spojení s dosti špatným chybovým hlášením Struts to vedlo k velmi pomalému růstu aplikace. Zvlášť v době, kdy jsem ke Struts neměl žádnou publikaci a vycházel jsem pouze z nápovědy. Při ladění kódu jsem musel na konzoli vypisovat hodnoty proměnných, kód byl protkán zápisy do souboru, ve kterém jsem potom hledal příčinu pádu aplikace. Druhým vývojovým prostředím byly NetBeans 5.0. Na rozdíl Elipse podporovaly alespoň základní knihovnu značek a dokonce jsem je propojil s JBoss serverem, ale pořád chyběla možnost vzdáleného ladění. Navíc oproti Eclipse byly Netbeans pomalé a náročnější na operační paměť. Koncem roku 2006 jsem nainstalovat Bea Workshop for Struts v 3.2.1 s 30ti denní zkušební verzi. Tento produkt mě uchvátil především podporou vzdáleného ladění zdrojového kódu, vynikající syntaktickou kontrolou značek Struts i konfiguračních souborů. Workshop for Struts je postaven na Eclipse, díky tomu byl znatelně rychlejší než Netbeans. Protože plná cena tohoto produktu je $400, snažil jsem se získat studentskou licenci, která ovšem neexistovala. Kontaktoval jsem sídlo firmy v Dallasu, kde mi doporučili obrátit se na On-line rezervační systém 42

Implementace

pražskou pobočku. Tady se mi podařilo získat „studentskou“ licenci na jeden rok. Rád bych touto formou poděkoval pánům Mikuláši Střeleckému a Michalu Kohútovi ze společnosti BEA. Jediným nástrojem používaným od začátku vývoje, je Struts konsole 4.8, která byla využívána k editaci konfiguračních souborů Struts. Databázi jsem editoval přes phpMyAdmin 2.6.3 a rozšíření QuantumDB Eclipse Plugin. Pro návrh databáze jsem použil DBDesigner a zkušební verzi MicroOLAP Database Designer for MySQL 1.9.2. Původní návrh databáze se rozrůstal, aniž se změny dokreslovaly do schématu, proto jsem zvolil program MicroOLAP, který pomocí ReverseEngineering vytvoří z databáze její schéma. Editace souborů s kaskádovými styly a s kódem JavaScriptu byla provedena v PsPad editoru 4.3.3. Tvorba diagramů proběhla v MS Visio, které je pro studijní použití volně dostupný. Zbylé náčrty a obrázky byly nakresleny ve vektorovém editoru Scribus 1.3.3 nebo v bitmapovém editoru Gimp 2.0.

5.1.3 Jakarta Struts podrobněji Popisování implementace by ztrácelo smysl, pokud nemáme alespoň základní přehled o fungování rámce Struts verze 1.2, která je použita při implementaci. V této kapitole budu citovat z knihy Programujeme Jakarta Struts 8.1. ActionServlet „Třída ActionServlet“ rozšiřuje třídu javax.servlet.http.HttpServlet a odpovídá za balení a směrování všeho, co přichází skrze HTTP na správná místa rámce ke zpracování.“ V pozdějších verzích funkci řadiče přijímá třída org.apache.struts.action.RequestProcessor, kterou lze rozšířit, čehož jsem využil. Action „Třída org.apache.struts.action.Action v rámci Struts je rozšířením komponenty řadiče. Funguje jako můstek mezi akcí klienta na straně uživatele a vnitřní funkcí.“ Z těchto citací plyne, že nakonfigurováním souboru web.xml, který se vyskytuje u většiny J2EE aplikací, předáme veškeré požadavky třídě ActionServlet a ta na základě námi nakonfigurovaného mapování vybere třídu Action, která požadavky propojí s vnitřní logikou, případně zpracuje. Přiřazování akcí „Přiřazení akcí je součástí konfiguračních informací Struts, které jsou uloženy ve zvláštním XML souboru. Tyto konfigurační informace se nahrávají do paměti při spouštění a jsou k dispozici za běhu rámce. Každý prvek Action je v paměti zastoupen instancí třídy org.apache.struts.action.ActionMapping. Objekt ActionMapping obsahuje atribut path, který koresponduje s částí URI příchozího požadavku.“ Určování příštího pohledu Hlavní metoda třídy Action, ve které s provádí to nejdůležitější, vrací jako návratovou hodnotu instanci třídy org.apache.struts.action.ActionForward. „Třída ActionForward reprezentuje místo určení, kam může řadič předat kontrolu poté, co byla akce dokončena.“ On-line rezervační systém 43

Implementace

Výhodu tohoto řešení spatřuji především v tom, že změna stránky nebude znamenat změnu kódu v Javě, ale pouze zásah do konfiguračního souboru. Pro lepší pochopení uvedu zdrojový kód třídy Action a její konfiguraci v xml souboru. 1.public final class RegistrationAction extends Action { 2. 3.public ActionForward execute( ActionMapping mapping, ActionForm form, 4. HttpServletRequest request, HttpServletResponse response) { 5. 6. RegistrationForm rform = (RegistrationForm) form; 7. RegistrationB rbean =new RegistrationB(getDataSource(request,"salon")); 8. MD5 md5 = new MD5(); 9. ActionForward forward = new ActionForward(); 10. 11. if (!(rbean.existLogin( rform.getLogin() ))) { 12. rbean.createUser( rform.getLogin(), rform.getName(), 13. md5.getHashString(rform.getPasswd()), rform.getSurname(), 14. rform.getTel(),rform.getEmail(),rform.getTitle(),"user"); 15. // vypuštěný kód 16. return mapping.findForward("success"); 17. } 18. System.out.println("registration failure"); 19. return mapping.findForward("failure"); 20. } 21. } 22.}

Zdrojový kód 1– Přiklad třídy Action

Pokud je akční třída volána, pak se vždy provede kód metody execute. Ve Zdrojový kód 1 se jedná o registraci nového zákazníka. Jedním z vstupních parametrů je ActionForm, který dopravuje data z HTML formuláře, v tomto případě registračního. Po provedení registrace se vrací objekt ActionMapping v závislosti na průběhu metody execute. Jeden návrat je vyhledáván pod řetězcem „success“ a neúspěšný návrat bude mapován na „failure“ stránku. Zdrojový kód 2 je z konfiguračního souboru struts-config.xml. Každá Action má přiřazenou cestu, pod kterou je volána z jsp stránek, v tomto případě /register, a pokud je takto volána, kontrolér zavolá definovanou akci (viz 2. řádek). Vazba každé akce na formulář je zmíněna na dalším řádku ukázky. Na čtvrtém a pátém řádku jsou definována přesměrování, která jsou v akci volána z objektu ActionMapping. 1. 2. 3. 4. 5. 6.

Zdrojový kód 2 – Ukázka konfiguračního souboru struts-config.xml

Pohledové komponenty rámce On-line rezervační systém 44

Implementace

„Objekty ActionForm se v rámci používají k tomu, aby předávaly klientská vstupní data mezi uživatelem a vnitřní vrstvou oběma směry. Rámec automaticky přijímá vstupní data z požadavků a předává tato data třídě Action pomocí formulářového beanu.“ Doplním fakt, že ActionForm je třída typu DTO (Data Transfer Object), tedy pro všechny definované proměnné, které mají přenášet informaci, je vytvořen getter a setter (metody musí mít stejný název jako proměnná plus předponu get/set). Navíc mohou být definovány metody mimo jiné validate(…) a reset(…). Reset(…) slouží k nastavení počátečních hodnot proměnných a validate(…) je využívána ke kontrole vstupů. Používání JSP k prezentaci „JSP stránka tvoří hlavní součást komponent pohledu ve Struts. Společně s knihovnami uživatelských značek a s HTML usnadňuje JSP v aplikacích práci s pohledy.“ Zde by se dalo polemizovat nad slovem „usnadňuje“. Při zobrazení jednoduchých stránek nezbývá než souhlasit, ale v případě netriviálního problému je výhodnější knihovny značek Struts obejít. I když během implementace byla vyvíjena značná snaha, aby výsledný kód byl čistě Struts, místy vyzněla kontraproduktivně. Zdrojový kód 3 je z přihlašovacího formuláře. Značka zastupuje logické když. Slovo logic je odkazem do knihovny značek strutslogic. Značka je nahrazován textem, který je v právě používaném jazyce přiřazen klíči logon.notLogged. Poslední komentovaná značka je . Zde bude ActionFormu s názvem LoginForm po odeslání formuláře do proměnné username pomocí settru přiřazena do tohoto pole uživatelem vyplněná hodnota. Tím se nám celý kruh uzavírá, protože username bychom zpracovali v akci, která má v konfiguračním souboru pod atributem path uvedeno „logon.do“.


Implementace

1. 2.
3.
4. 5.
6. 7.
8. 9. 10. 12. 13. 14. 16.
18. 19. 20. 21. 22. 23. 24. 25. 26.

/>

Zdrojový kód 3 – Ukázka jsp ve Strus

5.2 Stručný přehled použitých nestandardních knihoven 5.2.1 Knihovny Javy Jednu nestandardní knihovnu Javy jsem použil pro kreslení grafů. Přehlednost statistických čísel doplňuje koláčový graf vytíženosti personálu. Poměrně dlouho jsem hledal vhodný nástroj, dokonce jsem uvažoval o vlastní implementaci. Seznámil jsem se ale s JFreeChart 8.2, tedy volně šířitelnou knihovnou pro vykreslení grafů. Jedinou její nevýhodou je, že manuál je placený. I bez něj však lze poměrně snadno pochopit, jak graf nakreslit a uložit do souboru. Postup je k nahlédnutí v actionPackage.StatisticSaveAction v metodě drawChart.

5.2.2 Knihovny Struts Struts Layout Hned na začátku vývoje jsem narazil na Struts Layout (8.2) . Na domovských stránkách je uvedeno, že se jedná o knihovnu značek pro Struts, která poskytuje rychlou a jednoduchou tvorbu vzhledu stránek. Nepříliš složité stránky lze jednoduše upravit, ovšem jen za cenu toho, On-line rezervační systém 46

Implementace

že výsledný generovaný kód HTML bude tvořen pouze tabulkami. Z této knihovny jsem využil hlavně značek na zobrazení a ovládání kalendáře a značky pro vykreslení stručného výpisu. Tento výpis můžeme následně poměrně jednoduše řadit podle vybraných sloupců a dokonce stránkovat. Většina výpisů v této práci je vygenerována právě díky této knihovně. Bohužel nelze nijak ovlivnit to, co bude vygenerováno, protože posloupnost značek se nenačítá po jednom, ale překladač přečte více značek a na základě jejich posloupnosti generuje již zmíněný „tabulkový layout“. Vznikaly nepřekonatelné problémy s umístěním jednotlivých elementů. Navíc generovaný HTML kód nemusí být validní, u obrázků chybí alt popisek aj. AjaxAnywhere Druhou, o poznání menší, ale o to bezproblémovější knihovnou byla AjaxAnywhere 8.2. Knihovna splňuje to, co o ní její vývojáři hlásají. Pomocí AjaxAnywhere jsem pohodlně implementoval Ajax do aplikace, aniž bych musel napsat kód v JavaScriptu, což vzhledem k tomu, že polovina práce v technologii Ajax je řešena JavaScriptem, je pozoruhodné. Implementace se skládala z těchto kroků:  Vybrání oblasti kódu, který se měl obnovovat při volání AjaxAnywhere.  Při požadavku převezme řízení JavaScriptová část.  Na straně serveru vybereme, kterou z oblastí bude knihovna obnovovat.  Na straně serveru se připraví XML, které se předá klientovi.  JavaScript na straně klienta se XML transformuje na HTML a to je vloženo do zvolené oblasti. Mírnou nevýhodou je, že AjaxAnywhere neumí obnovovat např. jednotlivé řádky tabulky, ale autoři slibují tento nedostatek ve verzi 2.0 odstranit. Protože jsem z jednoho formuláře volal více Ajax požadavků, musel jsem si pomocí proměnných předávat, o kterou oblast se jedná, a na serveru potom z tohoto parametru volit metody, které požadavek zpracují.

5.3 Popis některých částí implementace Zvolil jsem několik implementačně zajímavých částí aplikace a nastínil jsem způsob, jakým byly tyto situace řešeny.

5.3.1 Rezervace Proces rezervace je popsán diagramem aktivit v kapitole 3.5.1. Níže je uveden postup, jakým jsou hledány volné místa pro vložení rezervace. Protože si zadavatel nepřál ukázat zákazníkům volné časy jeho zaměstnanců, bylo nutné objednávání řešit tímto způsobem:  Po kliknutí na odkaz rezervace se připraví všechny položky formuláře (generují se dynamicky z databáze v třídě Reserve) a zobrazí se stránka zachycená v příloze 8.2 na Obr. 25.  Zákazník si zvolí den v týdnu, datum, od kterého má zájem o službu, a datum, do kterého má být návštěva uskutečněna, denní dobu (dopoledne, poledne odpoledne), případně si zvolí konkrétního kadeřníka a/nebo kosmetičku. (Reservaion.jsp) On-line rezervační systém 47

Implementace



Program sestaví dotaz do databáze na základě získaných údajů (v ReservationAction). o Problémem je, když si zákazník nezvolí jednoho nebo oba obsluhující. Pak je nutné procházet všechny kadeřníky a sestavovat pro každého zvlášť dotazy do databáze. Pořadí vybíraní kadeřníků je určeno jejich aktuální vytížeností, což má dvě výhody:  budou všichni zaměstnanci vytíženi stejně (ale priorita se dá zvolit i ručně)  nejméně vytížený personál bude mít s největší pravděpodobností volno a hledání bude úspěšné dříve, než při náhodném výběru. o Pokud budou obsluhovat dva lidé, hledají se všechny kombinace dvojic personálu. o Konec hledání dalších dvojic nastane, pokud již je nalezeno dostatečné množství termínů (termíny se hledají v metodě findFreeTime, viz níže), v našem případě více jak 50, což je předpokládané množství, ve kterém se najde 5 časových okének pro zvolené služby (oněch 50 okének může být časově kratší než požadovaná doba návštěvy, takže teoreticky až 51. nabídka může být vyhovující). o Pokaždé, když je sestaven dotaz do databáze (pokud je určena obsluha, tak je jeden, pokud není určena obsluha, tak tolik, kolik je možných dvojic na obsluhu), je zavolána metoda findFreeTime (ta je v třídě Datum), která provádí následující:  Provede dotaz nad databází na otevírací hodiny ve zvolené dny (např. jen čtvrtky).  Sestaví se spojový seznam, v němž jsou na sudé pozici (od nuly) hodnoty OD KDY je otevřeno a na liché DO KDY, tj. tak se vytvoří dvojice dat, které vypovídají o otevřených hodinách.  V rozsahu data od, do (vstupní pole z formuláře) se zkontroluje databázová tabulka closed, zda není nějaký výjimečný den, tj. zkrácená pracovní doba.  Vybrané dny se zkrátí na dobu, kdy jsou oba členové vybraného personálu zároveň v práci.  Pokud je nějak omezena pracovní doba, změní se hodnoty prvků seznamu OD KDY či DO KDY –implementováno algoritmem MERGE SORT. − Posune se hodnota prvku seznamu OD KDY dozadu (zavřeno od rána, např. místo od 8h do 18h budou mít otevřeno od 12h do 18h). − Posune se hodnota prvku seznamu DO KDY dopředu (zavřeno večer, např. místo od 8h do 18h budou mít otevřeno od 8h do 15h). − Mezi původní hodnoty OD a DO se vloží další dva prvky seznamu. Je-li např. zavřeno 3.2.07 od 11h do 12h, pak se vloží mezi původní OD, DO, hodnoty 11:00 3.2.07 a 12:00 3.2.07. Při dalším čtení seznamu budeme vědět, že je otevřeno od OD KDY do 11:00 3.2.07 a pak je otevřeno od 12:00 3.2.07 do DO KDY. − Původní hodnoty OD a DO jsou celé překryty a budou vypuštěny.  Provede se již dříve sestavený dotaz do databáze na jednotlivé obsluhující v daném termínu a časech (výsledkem jsou časy a data, kdy personál nemůže, protože již pracuje nebo má dovolenou). Opět se upraví spojový seznam dat na základě výsledku daného dotazu. Tím se posunou časy začátku či konce volna, případně se vloží nové objekty typu Date. Opět tedy dochází k porovnávání prvků seznamu a výsledků z databáze. Jde o stejný princip jako u úpravy otevírací doby –MERGE SORT.


Implementace



 Takto upravený seznam je výstupem metody findFreeTime. o Nyní pokračuje běh metody ReservSationAction. Pokud není dostatečný počet výsledků, volá se metoda findFreeTime s jinými kadeřníky a kosmetičkami (viz výše). Výstup z opakovaného spuštění findFreeTime se přičte k předchozím (append). o Zjistíme odhadovanou dobu všech úkonů. Pokud lze některé úkony provádět paralelně, je výsledný čas menší než součet časů jednotlivých úkonů. o Procházíme spojový seznam dat a hledáme rozdíl časů, který je větší nebo roven odhadované době všech úkonů. Pokud je takový nalezen, je zařazen do pěti hledaných koncových nabídek. o Protože volný termín může být např. celý den, je nabídnuto více termínů než pouze jeden. Jestliže si uživatel zvolil dopoledne, pak může být výstupem funkce findFreeTime dvojice od 8h do 12h. Je proto nutné nabídnout více než jeden termín od 8h. Podle velikosti volna se nabídne termín od 8h, další od 8h+x (x je volitelná konstanta, implicitně 1h) a v závislosti na délce celé návštěvy také 12h minus délka návštěvy, tj. při 90min trvající obsluze se nabídne ještě termín 10:30. o Upravíme text podle zvoleného jazyka tak, aby na další stránce obsahoval informace o datu a čase začátku a jména obsluhujících. Zákazníkovi je nabídnuto až pět možností termínů, z nichž si může jednu zvolit (check.jsp) 0 1 2 3 4 5 0 1 2 3 4 5

Tue Jan 10 08:00 Tue Jan 10 12:00 Tue Jan 17 08:00 Tue Jan 17 12:00 Tue Jan 24 08:00 Tue Jan 24 12:00 Tue Jan 10 08:00 Tue Jan 10 12:00 Tue Jan 17 11:00 Tue Jan 17 12:00 Tue Jan 24 08:00 Tue Jan 24 12:00 Tue Jan 10 10:00 Tue Jan 10 12:00 Tue Jan 17 11:00 Tue Jan 17 12:00 Tue Jan 24 08:00 Tue Jan 24 12:00 úterý 24.1.07 od 8:00, obsluha Novák, Gott úterý 24.1.07 od 9:00, obsluha Novák, Gott úterý 10.1.07 od 8:00, obsluha Novák, Dlouhý úterý 10.1.07 od 9:00, obsluha Novák, Dlouhý úterý 24.1.07 od 8:00, obsluha Novák, Dlouhý

Takto vypadal seznam po porovnání s otevíracími hodinami. Uživatel si zvolil úterý dopoledne na nejbližších 14 dní.

Zde je upravený seznam po porovnání s tabulkou closed. Položka č.2 se změnila z původních 8:00 na 11:00. Někdo z vybraného personálu již měl 10. ledna do 10:00 nějaký závazek, proto se seznam upravil. Nabídka uživateli je omezena na 10. a 24. ledna, protože délka obsluhy je větší než 1h. Proto je 17. ledna nevyhovující.

Tab. 6 – Ukázka úpravy nabízených časů


Implementace



Zákazníkovi je zobrazen sumář objednávky (final.jsp), je vyžadováno přihlášení (pokud již není přihlášen), registrace či zanechání telefonu a jména pro ověření nezaregistrovaných uživatelů. Volba zůstane zachována i po registraci a přihlášení.  Poslední je buď informace, že vše proběhlo bez problémů, a nebo zpráva, že termín byl mezitím obsazen. Příklad úprav spojového seznamu dat je v Tab. 6.

5.3.2 Statická knihovna MyDate V rezervační části se v kódu vytváří Collection objektů Date. Velmi často se modifikují tak, aby udržovaly volné termíny. Postup, jakým se toho dosahuje již byl zmíněn. Většina metod objektu Date je deprecated, což znamená, že v novějších verzích Javy nemusí být podporovány. Veškeré časové operace se tedy provádí přes instance Calendar. Vzhledem k tomu, že při jedné rezervaci se provedou stovky úprav dat, je využití instance Calendar značně zpomalující. Proto byla napsána statická třída MyDate, která provádí základní operace s daty a časy. Při měření se ukázala především její paměťová nenáročnost oproti Calendar. Byl proveden test,kdy bylo vytvořeno stejné množství instancí Calendar a MyDate. MyDate objekt je značně jednodušší tím i menší (řádově) a rychlejší (18x) je i jeho tvorba (new MyDate())

5.3.3 Statistiky Výpočet statistiky je poměrně jednoduchý implementační problém. Uvedu pouze jednu optimalizační techniku. Výpočet statistik se provádí tak, že od zvoleného počátečního data po datum konečné se spočítá doba, kterou zaměstnanec  měl odpracovat (pracovní doba)  odpracoval  měl dovolenou. Z výsledku se potom podle vzorce odpracováno/(pracovní doba - dovolená) určí vytíženost. Ta je používána například při přidělování personálu jednotlivým návštěvám. Počítá se sedm dní před a sedm dní po aktuálním dnu. Tím se do výpočtu zahrnuje i plán a nemělo by dojít k přetížení pouze jedné osoby. Zmíněné vylepšení se týká ukládání často vypočítávaných statistik do databáze. Ve výpočtu poměrně dlouho trvá sčítání délky všech návštěv. Ale dotaz do databáze, zda již je výpočet provedený, je stokrát rychlejší. Do databáze jsou ukládány jen statistiky, které se nemohou měnit, tj. jen dat minulých. Zároveň se ukládají výpočty týdenní nebo měsíční (od pondělí do neděle nebo od prvního po poslední den v měsíci). Navíc lze archivní statistiky porovnávat i zpětně a vytvářet např. roční statistky ze statistik uložených. Vzhled statistik včetně grafu je v příloze 8.2 na Obr. 28.

5.3.4 Generování tabulky kalendáře Původní návrh a první implementaci práce s kalendářem provedl kolega Jiří Tománek. Výsledek ale nebyl optimální, protože jsme se se Struts teprve seznamovali, a ani požadavky na aplikaci nebyly kompletní. Bylo nutné tento návrh rozšířit a rozšíření přizpůsobit i stávající zdrojový kód. Mezi hlavní změny patří: zobrazení volitelného počtu zaměstnanců na volitelný On-line rezervační systém 50

Implementace

počet dnů, rozlišení osobního a globálního kalendáře, rychlé volby, zapracovat Ajax, kontrolu, spolupracovníka aj. Na tomto místě se krátce zmíním o zkušenostech získaných přepisem zdrojového kódu. Pokud se nejedná o velké množství dobře napsaného kódu, je vždy lepší začít programovat s úplným návrhem od začátku. Čas, který jsem potřeboval k pochopení cizího kódu a k následným úpravám, byl jistě menší, než by trvala implementace od počátku. Později se totiž objevovala spousta chyb právě v návaznosti částí dvou autorů, jejichž hledání a opravování (zvlášť bez možnosti ladění) zabralo rozhodně více času, než jsem čekal. Jiří Tománek napsal také jsp stránku diary.jsp, která vykresluje kalendář. Musel navrhnout způsob, jak řešit následující problém. Sloupce v kalendáři jsou přiřazeny zaměstnancům. Pokud má zaměstnanec nějakou návštěvu, je potřeba spojit buňky tabulky, aby tím byla zobrazena délka návštěvy. Tabulka v HTML se ovšem generuje po řádcích, je tedy potřeba zadat velikosti buněk ihned atributem rowspan (rowspan=3 znamená, že tři následující buňky v tomto sloupci budou spojeny). V cyklu s počtem opakování rovnému počtu řádků, v něm cyklus opakování pro počet sloupců a uvnitř vnořený cyklus, který testoval všechny na ten den naplánované návštěvy, zda jejich začátek neodpovídá řádku a personál neodpovídá sloupci, ve kterém se buňka právě generuje. Navíc se vnitřní cyklus prováděl dvakrát, jednou pro určení rowspan a podruhé pro vygenerování vlastního obsahu buňky. Při vykreslení 20 sloupců po 20 řádcích (5 členů personálu a pro každého 4 dny po 10h otvírací doba, kdy řádek je po půl hodině) a 100 návštěvách, tj. každý den 20 (5 na osobu) byly znatelné časové prostoje12 (jen vykreslování na serveru trvalo přes 3s). Složitost řádu O(n3) musela být nahrazena menší. Optimalizaci jsem provedl následujícím způsobem. Návštěvy jsou předávány do diary.jsp jako Collection. Protože do collection jsou objekty nesoucí informace o návštěvě vkládány již téměř seřazené13 (dotaz do databáze, vyžaduje výsledky vrátit seřazené), je řazení minimální časovou ztrátou. Collection je seřazena nejdříve podle času začátku návštěvy, dále zobrazovaných dat, třetím kritériem je id personálu. Toto řazení umožňuje využít vykreslování tabulky založené na shodě (podoba Merge-sortu). Vnitřní iterace přes všechny eventy se zkrátí na jediný test. Víme, že jsou data seřazená a pokud právě vykreslované buňce event neodpovídá, nebude této buňce odpovídat ani další event v Colletion (díky seřazení). Pokud odpovídá, zaznačí se jeho index a v dalších buňkách se bude testovat pouze další prvek v Collection. Zrychlení vykreslování tabulky použitím této metody nebylo o řád, jak jsem čekal, ale pouze asi třikrát. Změřil jsem čas překladu jednotlivých částí jsp souboru a zjistil jsem, že nejdéle trvá vytváření vnitřní části buňky. Zde se koncentruje více textu (především odkazy), který se vytváří ze v Struts proměnných pomocí operací s řetězci. Ty jsou pomalé, resp. stránku skládající se pouze z generovaného textu o velikosti cca 150kB generuje kolem 1s14.

12

Pro každé pole buňky (zde 400) bylo zkoušeno 100 návštěv, tedy 40 000 testů. Jsou spojeny tři seřazené kolekce: návštěv, dovolených a pracovních dob. 14 V průběhu testování, kdy stanice serveru nebyla na stejném PC jako zobrazovaný kalendář se výsledná doba generování tabulky zkrátila až na 0,2s. 13


Implementace

1.CURRENT=CURRENT.HEAD //první v kolekci 2.FOR EACH ROW as line 3. FOR EACH COLUMN as col 4. IF (ROWSPAN[col]>0) { //buňka je už plná 5. ROWSPAN[col]--; 6. CONTINUE; //tak ji nemusíme plnit 7. } 8. IF (CURRENT.column=col AND CURRENT.line=line ){//event sem patří 9. FILLCELL(CURRENT) //vložíme detaily 10. ROWSPAN[col]=CURRENT.rowspan //poznačíme si velikost 11. CURRENT=CURRENT.NEXT(); //a budeme hledat další 12. }ELSE { 13. FILLCELL(NULL) //vyplníme buňku bez eventu 14. } 15. END FOR EACH 16.END FOR EACH Zdrojový kód 4 – Pseudokód generování kalendáře

Když jsem začal vykreslovat více dnů kalendáře, musela být zvolena pracovní doba všech dnů od minimálních otevíracích po maximální zavírací hodiny. Byla-li ve výběru sobota, kdy byly pracovní hodiny jen dopoledne, a zároveň pátek, potom byly pro sobotu vykresleny stejné otevírací hodiny jako v pátek, protože jednu tabulku nelze rozpůlit. Navíc i ve stejných dnech může mít personál různou pracovní dobu. Začal jsem proto generovat události (návštěvy), které nebyly uložené v databázi, ale v kalendáři se vykreslují. Tyto události ohraničily každému zaměstnanci pracovní dobu. Jejich specialitou je, že pokud zaměstnanec bude chtít pracovat i mimo svou pracovní dobu, kliknutím na ně pak může následně vytvořit oficiální návštěvu. Generovaná událost, která ohraničuje pracovní dobu, se přizpůsobí a nebude překrývat skutečnou návštěvu. Naopak, pokud se klikne do pracovní doby, generovaná událost bude tvořit hranice časů, jež je možno využít k návštěvě. Součástí implementace kalendáře je metoda řešící překrývání generovaných a skutečných událostí. Ta využívá toho, že události v kolekci jsou seřazeny. Ten, který časově zasahuje do následujícího, je zkrátka oříznut. To si můžeme dovolit, protože lze s jistotou tvrdit, že ořezáváme pouze neexistující návštěvy. V příloze 8.2 je ukázka jednoho dne kalendáře na Obr. 31.

5.3.5 Ajax ve formuláři Event Předposlední věta z předešlé kapitoly platí právě díky technologii Ajax. Tomu, aby se události nepřekryly, slouží hlavní kontrola, která je prováděna těstě před vložením nové návštěvy a v případě konfliktu nebude vložena. Pokud bych se spolehl pouze na tuto kontrolu, bylo by založení nové návštěvy poněkud komplikované. Operátor by musel pohledem do kalendáře hledat vyhovující časy volna a ty


Implementace

potom volit u vznikající návštěvy. Pokud by při zakládání návštěvy do zvoleného časového výseku přibyla online objednávka, operátor by ji nemohl zaznamenat a došlo by ke konfliktu. Formulář Event využívá Ajaxu právě z toho důvodu, aby volený čas byl s velkou pravděpodobností volný a zároveň konzistentní. Návštěvy v kalendáři rozkouskují den zaměstnanců a nová návštěva může být vložena jen mezi již existující návštěvy. Od zvoleného času začátku se odvinou nabízené hodnoty konce. Pro názornost uvedu příklad. Čas 8:00 8:30 9:00 9:30 10:00 10:30 11:00 11:30 12:00

Kadeřník Návštěva 1

Návštěva 2 Návštěva 3

Nabídka začátků

8:00 9:00 9:30 10:30 11:30 12:30

Nabídka konce pro volbu začátku 9:00

9:30 10:00

Obr. 23 –Nabídka časů v zaplněném dnu

Začátky jsou omezeny jen na vzniklé ostrůvky volna a při jejich výběru se musí omezit časy eventuálního konce návštěvy jen na hodnoty mezi zvolenými ostrůvky. Podobná je situace při změně rozsahu již existující návštěvy. Kdybychom přeobjednávali návštěvu č.2 z Obr. 23, potom začátky konce jsou všechny hodnoty mezi 9:00 a 10:30 a hodnoty konce od 9:30 do 11:00. Na tomto místě je třeba uvést, kde všude a jakým způsobem je Ajax použit. Našeptávání je použito na dvou místech aplikace. Na formuláři návštěvy slouží k nápovědě celého jména objednávané osoby. V případě shody jména se zároveň načte telefonní číslo. O omezení časů jsem se již zmínil. To se provádí i v případě, že je zvolen druhý zaměstnanec k obsluze. Tady se navíc musí načítat i hodnoty začátků v závislosti na zvoleném spolupracovníkovi. Na formuláři návštěvy lze změnit i datum a hlavní obsluhující osobu, ale vzhledem k tomu, že se musí přepočítat všechna pole, je zde použití Ajaxu zbytečné. Zdrojový kód 5 upravuje konce nabízených časů u primárního personálu. Ukázka je relativně jednoduchá na pochopení. Potvrzený formulář je vždy odesílán ke zpracování jedné Action (zde SaveEvent). To, jestli byl formulář odeslán JavaScriptem Ajaxu, testuje metoda AAUtils.isAjaxRequest(request). Dalším povinným krokem je vybrání části HTML kódu, který se má upravit. V html kódu jsou značky označující místo k úpravě. Na jednom formuláři může být těchto zón více. Na jedné stránce však může být jen jeden formulář (viz kap. 5.4.). Metoda AAUtils.addZonesToRefresh(request, "endsSelect") určuje, kterou zónu budeme upravovat. Zbytek ukázky zdrojového kódu řeší změnu časové nabídky konce. Optimalizací při doplňování správných hodnot je jejich předpočítání a uložení. Pokud bude změněna hodnota začátku návštěvy, nemusí se znovu generovat všechny možnosti konců


Implementace

návštěvy a posléze z nich odebírat nepoužitelné hodnoty, ale postačí načtení a upravení přepočítaných (viz. řádek 19). 1.import org.ajaxanywhere.AAUtils; 2.//ostatní imports 3.//následující je ukázka z metody execute akce SaveEvent 4.//deklarace vypuštěny 5.if (AAUtils.isAjaxRequest(request)) { 6. if (frm.getHidden().equals("zacatek")){// jakou cast budeme refreshovat 7. AAUtils.addZonesToRefresh(request, "endsSelect"); 8. 9. try { //kdy po zvolenem zacatku je nejblizsi event? 10. rs=SqlQuestions.getNextEventStart(date, 11. frm.getId_personal(),start, 12. frm.getId_event(),db); 13. if(rs.next()&&rs.getString(1)!=null) { 14. //nalezen nejblizsi event 15. tmp=EventAction.removeAllAfter(rs.getString(1), 16. frm.getEndsSelectOriginal()); 17. //smaz vsechny nabidky po zacatku dalsiho eventu 18. } 19. else tmp=frm.getEndsSelectOriginal(); 20. //nechej puvodni 21. //predej novou nabidku koncu formulari 22. frm.setEndsSelect(EventAction.makeLabelValueBean( 23. EventAction.biggerThan(frm.getStart(),tmp))); 24. } catch (SQLException e1) { 25. //chybu ohlas velmi presne, kvuli ladeni 26. actionMessages.add(ActionMessages.GLOBAL_MESSAGE, 27. new ActionMessage("MySqlError", 28. "SaveEventAjax2","SQLexception")); 29. saveMessages(request, actionMessages); 30. e1.printStackTrace(); 31. return mapping.findForward("globalError"); 32. } finally { 33. db.close(); 34. } 35. } 36.return mapping.findForward("failed"); 37.} //konec ajaxu 38. // kód metody exekute pro klasické volání Zdrojový kód 5 – Ukázka použití knihovny AjaxAnywhere


Implementace

5.3.6 Server rutines Aby byly splněny požadavky na správnou funkčnost systému, musí existovat dvě služby, které budou spouštěny nezávisle na personálu. Jedná se o přepočítávání statistik, které by se měly spouštět několikrát za den. Jednou denně by měly být generovány a zasílány emaily připomínající klientům jejich návštěvy (emaily se budou posílat den před návštěvou). Instalace a implementace se skládá z těchto kroků:  Implementace třídy pro každou rutinu, která rozšiřuje org.jboss.system.ServiceMBeanSupport a implementuje SalonServiceMBean, Schedulable. SalonServiceMBean je rozhraní dědící z ServiceMBean.  Ve třídách dědících z ServiceMBeanSupport bylo potřeba překrýt několik metod a implementovat především metodu perform.  Dalším krokem k úspěchu bylo vytvoření souboru jboss-service.xml, ve kterém se pomocí xml značek definuje celá služba a její parametry. Podrobnější návod je uveden v internetových odkazech 8.2. V těchto službách jsem potřeboval využít databáze, ale třída MySQL získává připojení na základě parametru request15, který mimo Servlet nelze získat. Bylo proto potřeba nakonfigurovat server tak, aby bylo možné spojení získat přes třídu DriverManager. Postup konfigurace serveru je uveden v internetových odkazech 8.2. Následuje ukázka (Zdrojový kód 6) konfigurace služby, která jednou denně odešle emaily. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

<mbean code="org.jboss.varia.scheduler.Scheduler" name="salon.service:service=SalonServiceScheduler"> true services.SalonService 01.01.1970 9:45 86400000 -1 <depends>salon.service:service=SalonService

Zdrojový kód 6 – Konfigurace rutiny třídy ServiceMBeanSupport

Mezi základní atributy nastavení plánované služby patří na 3. řádku pravidlo, že při spuštění serveru bude služba určená na 5. řádku aktivní a nepředáme jí žádné parametry (7-10). Další nastavení je věnováno termínu prvního spuštění (11), periody (12), počtu opakování (13. řádek, -1 znamená nekonečně). 15

V dalších verzích Struts (od 1.3 novější) již není možné získat objekt DataSource z requestu.


Implementace

Tyto služby jsou nezávislé na operačním systému (cron vs. plánování úloh) a vytvoří se z nich při překladu balík s koncovkou .sar, který je možné použít na serveru JBOSS bez další konfigurace.

5.3.7 Centralizace kontroly přístupových práv Pokud se uživatel úspěšně autorizuje do systému, vytvoří se v session objekt UserContainer, který nese informace o uživateli. Jednou z nich jsou přístupová práva, tedy role, pod nimiž uživatel vystupuje. Každé stránce jsou v konfiguračním souboru strutsconfig.xml přiřazeny role, které mají právo danou stránku zobrazit (resp. zavolat požadovanou Action). Jak bylo v kapitole 5.1.3 zmíněno, než Controller předá řízení požadované akci, provede se kód v objektu org.apache.struts.action.RequestProcessor. Pokud tuto třídu rozšíříme, můžeme snadno kontrolovat práva přístupu centrálně v metodě processRoles a není nutné je kontrolovat v každé Action.

5.3.8 Validace Validaci považuji za jednu z nejzdařilejších částí Struts. Poměrně lehce se dají kontrolovat základní vstupy, jejich minimální a maximální délka, či formát data, telefonu nebo textu (více v příloze 8.2 na Obr. 30). Navíc se může generovat JavasSript kód pro každý formulář, který jej při potvrzení následně zkontroluje (viz. příloha 8.2 Obr. 29). 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

<arg key="logon.username" /> minlength 3 <arg0 key="logon.username" /> <arg1 key="3" resource="false" /> mask ${name}

Zdrojový kód 7 –Validace uživatelského jména při přihlašovaní

Pokud by nestačily předdefinované požadavky na vstupy, lze v metodě validade, která je ve formbeanech odvozených od org.apache.struts.validator.ValidatorForm, jednoduše kontrolovat veškeré vstupy a závislosti mezi nimi. V případě nedostatků bude controllerem On-line rezervační systém 56

Implementace

zobrazena výchozí stránka včetně chybových hlášení. Část definice kontroly přihlašovacího formuláře je zobrazena v Zdrojový kód 7.

5.3.9 Tabulkový výpis Se Struts-layout jsem se podrobněji seznámil až v konečné fázi projektu. Má některé nedostatky (viz. kapitola 5.2.2), ale velkou výhodou je jednoduchost, s jakou lze vytvořit tabulku, stránkování a řazení sloupců. Není pak zapotřebí nic více, než naplnit pole, které chceme zobrazit jako tabulku. Prvky tabulky jsou proměnné jednotlivých objektů uložených v poli. Zdrojový kód 8 vygeneruje obrázek Obr. 24, ale také i nepřehledný HTML kód. Značkou layout:pager žádáme o vytvoření max. 10 řádků na stránku, layout:collection předáváme naplněné pole a zobrazujeme vybrané prvky pole díky layout:collectionItem. 1. 2. 5. 7. 9. 11. 12. 13. Zdrojový kód 8 – Tvorba tabulky pomocí Struts-Layout

Obr. 24 –Výsledek použití Struts-Layout


Implementace

5.4 Chyby v použitých knihovnách Součástí každé implementace je řešení neočekávaných problémů. Některé se podaří vyřešit, některé se „obejdou“ jiným řešením a občas zjistíme, že chyba nebyla ve našem zdrojovém kódu, ale ve využívaných knihovnách.

5.4.1 Diakritická znaménka Čeština využívá oproti anglosaským jazykům diakritické znaménka. To vede k problémům správného kódování stránek a dat přenášených mezi pohledem a modelem Struts aplikací. Naštěstí se tento problém dá řešit překladem jednotlivých znaků do ascii kódování.

5.4.2 Názvy formulářů Každý vygenerovaný HTML formulář má své jméno. V HTML ho lze přiřadit formuláři atributem name. Ve Struts to není možné. Důvodem je to, že název formuláře určuje, který ActionForm data ze stránky převezme. To ovšem téměř znemožňuje použití více formulářů na jedné jsp stránce, protože jedné Action lze přiřadit pouze jeden ActionForm. Ve výsledku tedy jedna akce může zpracovávat pouze jeden formulář! Pokud bychom toto pravidlo dodržovali, bylo by množství Action i jsp stránek několikanásobné a orientace ve vytvářeném projektu by se značně snížila, zvlášť v konfiguračních souborech. Problémem je především to, že jedna akce naplní maximálně jeden formulář. Při zobrazení více formulářů na stránce, které by při odeslání volaly každý jinou Action, vzniká problém s naplněním těchto formulářů. Jediným řešením je zřetězit několik Action, které by plnily ty „své“ formuláře. A protože jsem se snažil většinu formulářů udržovat v prostoru stránky (request, nikoliv session), musela by každá akce volaná z této stránky zavolat znovu onen „řetěz“ plnících Action. Rozhodl jsem se situaci s více formuláři na stránce řešit tak, že všechny jsou zpracovány jednou Action a kód se provádí na základě předaného parametru. Až později při ladění aplikace jsem dospěl k poznání, že validace se provádí na základě jmen formulářů. V případě více formulářů se prováděla validace na všech formulářích, i když byl odeslán pouze jeden. Naštěstí se k řešení dalo využít tzv. stránkování formulářů. To bylo původně zamýšleno k validaci formulářů, které se rozprostíraly na více stránkách. Mně se podařilo takto odlišit formuláře na jedné stránce. Další problém (se shodným jménem více formulářů) přišel při použití značky z knihovny Struts-layout. JavaScriptem generovaný kalendář se zobrazil pouze v případě, že se nacházel v prvním formuláři na stránce. Bylo na něj (kalendář) odkazováno přes jméno formuláře, které nebylo na stránce unikátní. Nakonec jsem pozměnil funkci showCalendar() v souboru javascript.js. Bylo potřeba napsat funkci na vyhledávání správného formuláře. Ten jsem určil podle výskytu značky .

5.4.3 Validace V tomto odstavci se zmíním o úpravě, kterou jsem musel provést přímo v archivu commnons-validator.jar v souboru validateDate.js. Jedná se o podmíněnou validaci, která On-line rezervační systém 58

Implementace

proběhne pouze za splněné podmínky. Zde autoři nepředpokládali, že by se mohlo jednat o podmínku input field s atributem hidden. Opravy byly nutné provést i v konfiguračním souboru validator-rules.xml, kde validwhen přestalo validovat další vstupy po nalezení chyby. S validací souvisí i jeden nevysvětlený problém. Konfigurační soubor je třeba nahrát při spouštění serveru a téměř vždy se tak stane. Někdy ale validace není načtena a nejsou volány funkce pro validaci jak na serveru tak na klientovi. Problém by měla řešit novější verze Struts.

5.4.4 Nové verze Struts Je s podivem, že tak zkušený tým autorů déle nepodporuje metody zastaralé, resp. v nových vydáních Struts nahrazené jinými. Tím hodně komplikují rychlejší rozšíření novějších verzí, protože získané výhody nové verze jsou zaplaceny přepisem vlastního kódu aplikace. Navíc není vždy jednoduché rozpoznat, zda se jedná o chybu způsobenou novější verzí Struts. Příkladem zdrojů problému byly metody např. getDatasource z Action, třídy ActionErrors či knihoven Javascriptu. Toto je jeden z důvodů, proč tato práce využívá Struts 1.2 s některými vlastními úpravami kódu.

5.4.5 Generovaný HTML kód knihovou Struts Layout Překlad zapsaných značek je řízen vlastními knihovnami Struts Layout. Autoři ve snaze vytvořit co nejjednodušší způsob tvorby vzhledu stránky zapomněli na podstatnou věc. Většina HTML elementů je generována do tabulky, aby se lehce určila jejich pozice v rámci stránky. Často proto vznikne kód, kdy jsou v sobě vnořeny tabulky, čímž se stránky stávají nečitelné pro osoby využívající programy, které jim stránky „předčítají“. Navíc je velmi komplikované ovlivnit pozice vygenerovaných tabulek, protože některé nelze obklopit značkami
. To je pravděpodobně způsobeno tím, že překladač nenačítá značky Struts-layout jednu po druhé, ale načte jich více zároveň a pokud jsou v logické souvislosti, generuje pro ně jiný kód, než kdyby se vyskytovala jen jedna.Viz kapitola 5.2.2. Navíc u generovaných značek často chybí atributy, které jsou v HTML 4.01 povinné, jako alt u obrázků nebo upřesnění typu u značky <script>. Z tohoto důvodu nejsou některé výsledné HTML stránky projektu validní.

5.5 Možná vylepšení algoritmů 5.5.1 Algoritmus vyhledávání volna pro rezervaci Při implementaci výpočtů statistiky mě napadlo, jak ještě efektivněji řešit hledání volného času. Stejně jako u statistik by se do databáze ukládaly spočítané hodnoty (aktuální hodnoty volna). Vždy při prvním dotazu na daný den by byly vypočítány pracovní hodiny pro všechny zaměstnance, byly by upraveny o případnou dovolenou a uloženy do databáze. Vložení rezervace by znamenalo čas volna uložený v databázi upravit. Tímto způsobem by se pořád udržovaly informace o volnu vždy jen v potřebných dnech, protože volno ve dnech již minulých by se mazalo. Nutností by bylo při zadání, změně či smazání rezervace a dovolené ihned provést přepočet hodnoty volna zaměstnanců v databázi. On-line rezervační systém 59

Implementace

5.5.2 Nákupní košík Lepší přehlednost nabízených služeb by nabízely stránky věnované popisu jednotlivých procedur včetně ceny a časové náročnosti, doplněné o fotografie. Uživatel by si mohl lépe představit, co která služba nabízí a vybrané procedury by si vložil do „košíku“. Při zahájení nové rezervace by se zvolili procedury nacházející se v košíku.

5.5.3 Vzájemné vyloučení služeb Současná verze systému neřeší možné vazby mezi nabízenými procedurami. Zákazník volí služby podle svého uvážení. Ilustrativní příklad: Zákazník zvolí střih dlouhých i krátkých vlasů. Systém sečte časy obou procedur a hledá takto dlouhý časový úsek. Až operátor při kontrole nové objednávky zaregistruje, že procedury jsou zvoleny nelogicky a bude kontaktovat zákazníka. Podobným způsobem by se mohly svazovat procedury, které lze provádět paralelně. Nyní se paralelně provedou procedury, které mají určený paralelní čas. Opět se neřeší situace, ve které dvě konkrétní procedury zároveň nemohou být provedeny, ale s jinými procedurami ano.


Testování

6 Testování Cílem testování softwaru je najít co nejvíce chyb, aby mohly být následně odstraněny.

6.1 Jednotkové testy Testy jednotlivých částí aplikace jsem prováděl vždy s jejich implementací. Testování probíhalo pomocí metody white-box a týkalo se zejména:  Okrajové podmínky (zda modul správně pracuje na hranicích omezujících výpočet)  Nezávislé testy ( zda může být příkaz proveden alespoň jednou)  Cesty pro zpracování výjimek (zda je každá výjimka dostatečně ošetřená)  Zda volání metod přináší očekávané změny (v databázi)  Funkčnost jednotek – každá metoda byla volaná několikrát, pokaždé s jinými vstupy, aby mohla být dostatečně ověřena její činnost. Jednotkové testy odhalovaly chyby jak sémantické, tak systematické či logické.

6.2 Integrační testy Testování integrace částí mělo za úkol zkontrolovat správné odezvy určitých celků na akce prováděné v jejich souvisejících částech. Tuto část testování jsem prováděl vždy po dokončení logického celku aplikace (většinou tyto celky odpovídaly jednomu modelu jednání). Odhalené chyby jsem okamžitě odstraňoval a celé testování jsem po této opravě začal vždy od počátku, protože občas se stalo, že po „opravení“ jednoho problému vznikl problém jiný. Tento postup testování bývá označován jako metoda inkrementální integrace. Tedy postupně se testují dílčí integrované části a nakonec integrace celého systému. Integračním testováním jsem prováděl verifikaci programových konstrukcí za pomocí BlackBox testování. Vzhledem k rozdělení aplikace do jednotlivých Action a možnosti vzdáleného ladění jsem většinou neměl problém chybu nalézt, ale spíše byl problém chybu odstranit tak, aby nebyla narušena funkčnost. Integračními testy jsem prověřoval zejména:  Správnou funkčnost prezentační vrstvy (stránky v prohlížeči a jejich validace)  Součinnost prezentační vrstvy a logické vrstvy (přenos dat od pohledku k modelu)  Spojení logické vrstvy aplikace s databázovým serverem

6.3 Testy uživatelského rozhraní Jedná se o testování reakcí aplikace na uživatelovy vstupy a požadavky. Testy je potřeba provést alespoň na základních prohlížečích www stránek (IE 6, IE 7, Mozilla Firefox, Opera). On-line rezervační systém 61

Testování

Testována byla především vstupní pole, která byla vyplněna jak validními, tak nevalidními vstupy, a reakce systému. Dále byla kontrolována reakce na podněty z tlačítek a pohybu myši nad poli, kde může být spuštěna nějaká akce (onclick, onblur aj.).

6.4 Validační a systémové testy, akceptace a testy použitelnosti Validační testování bude probíhat spolu s testováním systémovým. Systémové testování prakticky ověřuje funkčnost systému v prostředí jeho reálného nasazení. Validace pak testuje, zda daný software splňuje rozumná očekávání zákazníka. Výsledky těchto testů pak rozhodnou o akceptaci systému. O akceptačních testech a testech použitelnosti jsem se zmínil v kapitole 4.4.

6.4.1 Testy použitelnosti Ve chvíli kdy se projekt dostal do fáze, kdy byly odstraněny chyby, které bránily používání, připravil jsem jednoduchý test. Měl odpovědět na otázku, jak složitá je rezervace návštěvy v salónu. Každá testovací osoba byla seznámena s úkolem níže popsaným způsobem. Motivace Právě jste na narazili na www stránku. Zaujala vás svým obsahem, a protože v blízké době plánujete návštěvu kadeřníka, objednejte se. Vyberte si, jaké služby vás zajímají. Čas volte také podle skutečnosti. Očekávaný postup Uživatel si přečte úvodní stránku „O nás“. Dozví se, že registrace je dobrovolná a jaké z toho plynou výhody. Může se zaregistrovat nebo si začne vybírat možnosti z rezervačního formuláře bez registrace. Při případné úpravě data návštěvy (od a do) použije ikonu kalendáře k jeho jednoduchému vyvolání a nastavení termínu. Po odeslání se v případě nenalezení žádného volného termínu vrátí pomocí tlačítka zpět. Pokud bude termín navrhnut, zvolí ten nejlépe vyhovující a výběr potvrdí. Na poslední stránce, pokud je přihlášen, pouze potvrdí volbu. Jinak se zaregistruje nebo zanechá kontaktní jméno a telefon. Testovací prostředí Většina testů byla provedena na osobním počítači testované osoby. Rozlišení na testovacích monitorech bylo v rozmezí od 800x600 do 1200x1024. Všechny počítače měly dostatečně rychlé připojení k Internetu. Důvodem testování osob v jejich domácích podmínkách bylo, že většina uživatelů s Internetem pracuje výjimečně a v nezvyklém prostředí by se nemuseli vyznat (různé typy prohlížeče aj.). V místnosti byla jen testující osoba a pozorovatel, který zapisoval netypické postupy.Pozorovatel nijak nereagoval na dotazy testující osoby. V době testování server běžel na stroji s 256 MB RAM, CPU 900 MHz což jsou parametry pod minimem požadavků, přesto tímto test nebyl ovlivněn.


Testování

Účastníci testu Osoby účastnící se testu byly záměrně zvoleny spíše ze skupiny občasných či nových uživatelů Internetu. Počet mužů ku počtu žen byl vybrán podle reálných odhadů poměru zákazníků, tedy 3:7 ve prospěch žen. Snaha byla pokrýt všechny věkové skupiny. Zkušenosti práce uživatele s Internetem byly hodnoceny školním systémem (1-vynikající, 5nedostatečný).

Označení Osoba č. 1 Osoba č. 2 Osoba č. 3 Osoba č. 4 Osoba č. 5 Osoba č. 6 Osoba č. 7 Osoba č. 8 Osoba č. 9 Osoba č. 10

Pohlaví Muž Muž Muž Žena Žena Žena Žena Žena Žena Žena

Věková kategorie (let) 20-30 10-20 50-60 60-70 50-60 10-20 40-50 30-40 50-60 10-20

Využití Internetu Denně, studium a zábava Denně, spíše zábava 2x týdně, koníčky, banka Připojení má krátce, zábava 2x týdně, jen pro pracovní účely Denně, zábava Denně, zprávy, práce, zábava 1x týdně, práce 3x týdně, komunikace, informace Denně, zábava, škola

Hodnocení zkušenosti uživatele s Internetem 1 2 3 4 3-4 2 2 4 3 1

Návštěva salónu Ne Ne Ne Ano Ano Ano Ano Ano Ano Ano

Tab. 7 - Účastníci testu použitelnosti

Výsledky testů Osoba č. 1 provedla rezervaci bez problémů, neregistrovala se a využila zanechání kontaktních údajů. Osoba č. 2. na úvodní stránce vložila do pole „Uživatelské jméno“ své jméno, zadala i heslo. Aplikace zahlásila, že uživatelské jméno neexistuje. Osoba pak 20s přemýšlela, než se rozhodla rezervovat si služby, také bez registrace. Svůj postup zdůvodnila tím, že formulář pro přihlášení byl oproti ostatním elementům stránky příliš výrazný, naopak odkaz menu „Rezervovat se“ byl malý. Při kontrole dat návštěvy využil kalendář Windows místo na stránkách umístěného kalendáře. Osoba č. 3. bez jakéhokoliv zkoumání provedla registraci a poté se zvolila procedury a objednala se. Osoba č. 4 vyplnila formulář pro přihlášení svým emailem a když se jí přihlášení nepovedlo, zaregistrovala se. Při rezervaci se nenašel volný termín v časovém rozpětí, které požadovala, ale dokázala si zvolit jiný. Nelíbil se jí popis tlačítka „Navrhnout termíny“, protože ona již svou volbou navrhla, kdy má o návštěvu zájem. Osoba č. 5 opět vyplnila formulář pro přihlášení, přitom nebyla zaregistrována. Dále se rozhodla pokračovat v rezervaci bez registrace. Při volbě dat použila formulář. Na formuláři, kde se zanechává kontakt (telefon a příjmení), pouze potvrdila tlačítko formuláře bez vyplnění kontaktních údajů. Aplikace zahlásila, že příjmení a telefon je povinný. Testující osoba ale On-line rezervační systém 63

Testování

místo do formuláře vyplnila hodnoty Uživatelské jméno a heslo, které slouží k přihlášení do systému (a jsou v jiném formuláři). Aplikace opět upozornila na neexistující údaje. Osoba nakonec vyplnila správný formulář. Osoba č. 6. bez studování stránek se zaregistrovala a objednala se bez problémů. Osoba č. 7. se bez jakýchkoliv rozpaků zaregistrovala. Při rezervaci se vyskytly komplikace s nalezením volného termínu, ale situaci vyřešila bez zaváhání. Osoba č. 8 při prvním setkáním se stránkou začala vyplňovat jméno a heslo přihlašovacího formuláře, ale nebyla přihlášena. Po malém bloudění se rozhodla zaregistrovat. Jako uživatelské jméno uvedla „jméno příjmení“ i s mezerou. Systém nezahlásil chybu a uživatelské jméno bylo platné. Rezervace proběhla bez problémů. Osoba byla nespokojena s informacemi ohledně nabízených služeb. Osoba č 9: První kroky vedly k registraci, která proběhla bez problémů. Následná objednávka se taktéž nijak nezkomplikovala. Osoba č. 10: Jako jedna z mála si přečetla úvodní stránku a rezervaci provedla bez registrace. Neuvědomila si , že takto přijde o možnost pozdější kontroly či přeobjednání. Při použití data změnila měsíc, ale volbu nepotvrdila, datum zůstalo nezměněno. Zbytek rezervace provedla bez problémů. Hodnocení testů Pozitivem testů je, že všechny testované osoby našly termín, který by jim vyhovoval, a dokázali si ho rezervovat. Tři osoby využily ve stránce nabízeného kalendáře, pouze jedna si jej nevšimla. Velmi nepříjemné je zjištění, že uživatelé ve třech případech vyplnili formulář pro přihlášení, aniž by byli registrováni (pohled na Obr. 25 v příloze 8.2 napoví více o rozložení stránky). Jedna osoba navíc po zadání špatných údajů vyplnila tento formulář, místo formuláře v nabídnuté stránce. Většina testovaných osob nejdříve vyplnila registraci, aniž si ověřili, že jim systém nabídne vhodný den návštěvy. Žádná z testovaných osob si nevšimla krátké nápovědy, která se zobrazí nad jednotlivými službami. Testování bylo hodně ovlivněno tím, že systém nenabídl statické stránky, ve kterých by byly popsány zejména nabízené procedury, uvedeny otevírací hodiny Salónu a fotogalerie. Návrhy na úpravy Další testy použitelnosti by měly proběhnout i se všemi statickými stránkami. Za velmi vhodné je považováno naprogramování stránky, kde budou detailně popsány nabízené procedury a bude možno si je „vložit do košíku“. Ty se zobrazí jako vybrané na prvním formuláři rezervace.


Testování

Otázkou zůstává, zda se má přesunout formulář sloužící k přihlašování do systému. Je možné, že přibudou-li odkazy na statické stránky a formulář se zmenší a nebude tak výrazný, lidé jej nebudou vyplňovat, aniž by byly registrováni.

6.4.2 Systémové testy V poslední fázi vývoje byla práce zveřejněna na dostupné www adrese a autor požádal zdatné uživatele internetu o testování části pro klienty (security testing, stres testing, recovery testing viz 8.1). Díky tomuto testování bylo odstraněno několik chyb. Za velmi pěkné popsání kroků, které vedly k pádu aplikace, jim moc děkuji.

6.4.3 Plán testů Bohužel se nepodařilo zajistit naplnění databáze na takovou úroveň, aby se testy daly považovat za zátěžové. Hlavním problémem je naplnění databáze, kde se nesmí jednotlivé návštěvy u personálu překrývat, a napsání generátoru testovacích dat je proto komplikovanější. Přesto se před případným nasazením musí provést testy s jednoročním zaplněním databáze (cca 20 000 návštěv, 300 registrovaných uživatelů). Je potřeba provést testy použití na část aplikace pro operátora a personál, pro zákazníky pak testy opakovat s opravením chyb nastíněných v předešlé kapitole.


Závěry

7 Závěry Úkolem této práce bylo navrhnout a implementovat základní verzi systému, který udržuje návštěvy klientů a umožňuje klientům vlastní schůzky spravovat. Nejdůležitější částí systému není část klienta, jak by se mohlo zdát, ale část operátora. Ten zakládá a upravuje návštěvy klientů, kteří nevyužijí on-line rezervace. K jednoduché správě systému slouží část pro administrátora. Závěr je rozdělen do tří částí. V první je rozebráno, zda zvolené technologie pro tento projekt byly vhodné. Dále jsou shrnuty dosažené výsledky a v poslední části kapitoly jsou doporučení pro další pokračování projektu. Vhodnost zvolených technologií Součástí hodnocení práce je diskuze, zda zvolené technologie a jazyky byly pro tuto práci vhodné. Ze zadání práce plynulo použití rámce Jakarta Struts, který je implementován nad jazykem Java. Rámec Struts se za dobu vývoje práce vylepšoval a vznikaly nové verze, což mělo své výhody, ale i zásadní nevýhody v podobě velkých zásahů do některých částí knihoven, které nebyly zpětně kompatibilní se Struts starších verzí. Tato práce by se dala svým rozsahem zařadit mezi středně velké aplikace. Při udržování vývojových konvencí by bylo možno použít i jazyk php. Jeho výhodou je přehledné chybové hlášení, kvalitní podpora knihoven a rychlejší (přímočařejší) vývoj. Ve Struts bylo třeba psát zdánlivě zbytečný kód v podobě ActionForms (více v kapitole 5.1.3), který odpovídal asi čtvrtině zdrojového kódu celého projektu. Práce v php je jednodušší než ve Struts, protože zdrojový kód přímo ovlivňuje stavbu i obsah stránky a není potřeba nastavovat konfigurační soubory. Tyto výhody platí pouze do určité velikosti projektu. Vývoj ve Struts je zpočátku velmi pomalý a více než programování se autoři věnují nastavení Struts. Jakmile programátor pochopí základní souvislosti, je mu odměnou velká variabilita projektu. Změna vzhledu neovlivní logickou vrstvu a naopak, snadná validace i směrování na stránky jsou jistě výhodami. Největší pozitivum Struts (resp. aplikace typu Model-View-Controller, což Struts je) je možnost využití celého modelu aplikace a napojení na jiné GUI založené např. na knihovně Swing , protože logika systému je na rámci nezávislá. JSP má ve výsledku stejné výhody i nevýhody jako php a navíc využívá kvalitnějších knihoven Javy. Diskuze by měla srovnat Struts s podobnými rámci či nástroji jako např. Java Server Faces a Microsoft .NET. Nemám s nimi zkušenosti, a proto je nemohu kvalifikovaně porovnávat. V Java Server Faces 8.2 lze psát efektivněji, ale chybové hlášení není o mnoho lepší než ve Struts. Microsoft .NET 8.2 je nevýhodný především svým komerčním pojetím, ale vývojovým prostředím a chybovým hlášením překonává zmíněné technologie využívající Javu.


Závěry

Technologie Ajax měla neoddiskutovatelný přínos pro rychlost a přehlednost ovládání části aplikace určené zaměstnancům. Překvapivá byla jednoduchost zapracování této techniky do projektu s využitím knihovny AjaxAnywhere. Server Jboss 4.0 splnil předpoklady kvalitního produktu nejen pro vývoj. Nedostatky se projevili při správě paměti, kdy při častém znovunačítání zdrojového kódu (při vývoji) serveru docházela paměť. S databází MySQL 5.0 nebyly za celou dobu vývoje žádné problémy a splnila veškeré požadavky. V návrhu práce stálo za zvážení využití rámce pro mapování dat mezi objektově orientovaným (Struts) a relačním (MySQL) světem. Mohlo se jednat o Hibernate 8.2 nebo iBatis 8.2. Rámec Struts s výhradami splnil požadavky, které na něj byly během vývoje kladeny, ale vzhledem k tomu, že se v porovnání se JSF a .NET jedná o nejstarší rámec, jsou výhody spíše na straně mladších technologií. Několik nevýhod Struts je popsáno v kapitole 5.4. Pokud bych měl současné zkušenosti se Struts a znovu se rozhodoval, zda tento rámec využít, pravděpodobně bych tak učinil, protože jej znám. Naopak bez jakékoliv znalosti Struts bych čas raději věnoval studiu jiného rámce. Zhodnocení dosažených výsledků V této práci je dokumentován celý vývojový cyklus rezervačního systému kadeřnického salónu. Přestože byl návrh konzultován se zadavatelem a výsledný produkt je „šitý“ na míru právě salónu krásy, lze systém využít ve všech odvětvích, ve kterých je potřeba rezervovat čas obsluhy v závislosti na vybraných službách. Jednoduše lze zaměnit názvy kadeřnických úkonů za operace prováděné dentistou či personálem pneuservisu. Můžeme konstatovat, že se jedná o univerzální rezervační systém služeb, ve kterém systém zákazníkovi nesdělí vytížení společnosti a jednotlivých zaměstnanců, ale nabídne mu termín podle jeho požadavků. Diplomová práce splňuje cíle, které byly stanoveny v kapitole 2.7. Rezervace zákazníkem probíhá tak, aby uživatel nebyl nucen k registraci či přihlášení se do systému. Navíc lze rezervaci provést v pouhých třech krocích. Výhodou registrovaných uživatelů je možnost spravování vlastních objednávek. Zaměstnanci získávají přehled nad svými povinnostmi z jakéhokoliv počítače s přístupem na Internet, navíc je můžou spravovat. Založení či zrušení rezervace je jak zákazníkovi, tak personálu oznámeno emailem. Hlavní částí systému je celek sloužící ke správě všech událostí. Několika způsoby lze nalézt vhodný termín pro zákazníka, který k rezervaci nevyužije on-line rezervace. Mezi výhody patří kontrola vzniku konfliktu a návrh jeho řešení při vkládání či editaci události (návštěvy či dovolené), zobrazení práce vybraného personálu na volitelný počet dní (v kalendáři), automatické přiřazení návštěvy registrované osobě. Samozřejmostí jsou přehledy provedených úkonů, nastavení pracovních hodin, personálu a nabízených služeb. Operace spojené s rezervací a správou návštěv jakožto velmi komplexní úlohy, byly optimalizovány co se týče algoritmů, rychlosti výpočtů a uživatelské přívětivosti. Současná verze systému zahrnuje plně odladěnou část databáze. Logická část aplikace obsahuje všechny požadavky shrnuté v kapitole 3.3. Rezervace zákazníkem byla podrobena testům použitelnosti (více v kapitole 6.4.1) i testům většího množství uživatelů a je odladěná. Celek pro personál je stabilní. Vzhled stránek je pouze pracovní, nikoliv finální, stejně jako


Závěry

texty na stránkách a v automaticky odesílaných emailech. Pro plnou funkčnost je potřeba doplnit statické stránky informující o procedurách, salónu aj. Systém je připraven na akceptační testy. Doporučení pro další pokračování projektu K tomu, aby byl systém prohlášen za stabilní, a mohl by být nasazen do ostrého provozu, je potřeba provést zátěžové testy (viz kapitola 6.4.3). Prvních několik měsíců by měl být společně s aplikací paralelně veden záznam používaný doposud, aby bylo možno odladit případné chyby s hlubšími závislostmi. K dokončení projektu je nutno provést zmíněné testy a doplnění aplikace statickými stránkami, které by informovaly o nabízených službách a salónu. Samozřejmostí je doplnění kvalitního vzhledu aplikace, který je pro toto odvětví nepostradatelný. Doporučoval bych implementování fotogalerie, do které by se mohly přidávat fotografie obsloužených klientů. Ti by mohli při další návštěvě požadovat provedení shodné s minulou návštěvou, jejíž výsledek je zachycen na fotografii. Navíc by uživatel k rezervaci mohl připojit fotografii požadovaného účesu.


Seznam literatury

8 Seznam literatury 8.1 Seznam literatury [1] CAVANESS, CH. PROGRAMUJEME JAKARTA STRUTS. GRADA PUBLISHING, A.S, PRAHA, 2003. [2] ARLOW, J. – NEUSTADT, I.: UML 2 A UNIFIKOVANÝ PROCES VÝVOJE APLIKACÍ. COMPUTER PRESS, A.S, BRNO 2007. [3] BLOCH J. JAVA EFEKTIVNĚ. GRADA PUBLISHING, A.S, PRAHA 2002. [4] ASLESON, R., SCHUTTA, N. T. AJAX – VYTVÁŘÍME VYSOCE INTERAKTIVNÍ WEBOVÉ APLIKACE. COMPUTER PRESS, A.S, BRNO 2006. [5] DARWIN , I. F.: JAVA – KUCHAŘKA PROGRAMÁTORA. BRNO 2006. [6] MANNOVÁ B., VOSÁTKA K. ŘÍZENÍ SOFTWAROVÝCH PROJEKTŮ. PRAHA 2005 [7] RICHTA K. SLIDY PRO PŘEDMĚT X36SIN. PRAHA 2006 [8] SCHMIDT J SLIDY PRO PŘEDMĚT X36SCP. PRAHA 2006

8.2 Internetové odkazy [9] KONFIGURACE PŘIPOJENÍ JBOSS 4.0 K MYSQL DATABÁZI (ALE HTTP://WWW.ONJAVA.COM/PUB/A/ONJAVA/2004/02/25/JBOSSJDBC.HTML#MYSQL [10] TUTORIÁL K PSANÍ RUTIN NA SERVERU HTTP://BLOG.PLATINUMSOLUTIONS.COM/NODE/85 [11] KONFIGURACE JBOSS SERVERU HTTP://WIKI.JBOSS.ORG/WIKI/WIKI.JSP?PAGE=JBOSSRUNPARAMETERS [12] AJAX NA WIKIPEDII HTTP://EN.WIKIPEDIA.ORG/WIKI/AJAX#HISTORY [13] IBATIS DATA MAPPER HTTP://IBATIS.APACHE.ORG/ [14]HIBERNATE – RELATIONAL PERSISTENCE FOR JAVA AND .NET HTTP://WWW.HIBERNATE.ORG/ [15]JAVA SERVER FACES HTTP://EN.WIKIPEDIA.ORG/WIKI/JAVASERVER_FACES [16].NET FRAMEWORK HTTP://EN.WIKIPEDIA.ORG/WIKI/MICROSOFT_.NET_FRAMEWORK [17] JAVA SERVLETY – SERIÁL HTTP://INTERVAL.CZ/SERIALY/JAVA-SERVLETS/ [18]DOKUMENTACE KE STRUTS HTTP://STRUTS.APACHE.ORG/ [19]DOKUMENTACE KE STRUTS-LAYOUT

I

JINÝM)

JBOSS


Seznam literatury

HTTP://STRUTS.APPLICATION-SERVERS.COM/DOC/INDEX.HTML [20]DOKUMENTACE K AJAXANYWHERE HTTP://AJAXANYWHERE.SOURCEFORGE.NET/ [21]DOKUMENTACE K MYSQL 5.0 HTTP://DEV.MYSQL.COM/DOC/REFMAN/5.0/EN/ [22]BEA WORKSHOP FOR STRUTS HTTP://WWW.BEA.COM/FRAMEWORK.JSP?CNT=INDEX.HTM&FP=/CONTENT/PRODUC TS/WO RKSHOP/STRUTS [23]KNIHOVNA REGULÁRNÍCH VÝRAZŮ HTTP://REGEXLIB.COM/SEARCH.ASPX [24]ČLÁNEK ZABÝVAJÍCÍ SE VALIDACÍ STRUTS HTTP://RAIBLEDESIGNS.COM/RD/ENTRY/STRUTS_VALIDATOR_VALIDATING_TWO_FIELDS [25] PROČ VYBRAT STRUTS HTTP://WWW.DIGITALSOLUTIONS.PH/NODE/20 [26]DOMÁCÍ STRÁNKY JBOSS HTTP://WWW.JBOSS.COM [27] JBOSS NA WIKIPEDII HTTP://EN.WIKIPEDIA.ORG/WIKI/JBOSS [28] ZDROJ OBR. 11 HTTP://WWW.IBM.COM/DEVELOPERWORKS/CN/WEBSPHERE/TECHJOURNAL/0304_BARO SA/BAROSA.HTML

[29] ZDROJ OBR. 12 HTTP://JAVA.SUN.COM/DEVELOPER/TECHNICALARTICLES/J2EE/AJAX/

[30]JFREECHART – KNIHOVNA K JEDNODUCHÉMU KRESLENÍ GRAFŮ HTTP://WWW.JFREE.ORG/JFREECHART/


Přílohy

Formulář akceptačního testu


Přílohy

A Ostatní tabulky databáze Název sloupce id_log user_id_user logtime

Datový typ int(13) int(10) datetime

Primární klíč ANO NE NE

Nenulový ANO ANO ANO

Tab. 8 - Entita log (* Entita zatím není využívána a lze očekávat její rozšíření) Název sloupce

Datový typ

Nenulový

int(11) tinyint(4)

Primární klíč ANO NE

id_openhours Day Open Close

Default hodnota

Poznámka

ANO ANO

0

Den v týdnu je vzhledem k opakování dostačující

time time

NE NE

ANO ANO

00:00:00 00:00:00

Tab. 9 - Entita openhours Název sloupce id_event Day

Datový typ int(11) tinyint(4)

Primární klíč FK NE

Nenulový ANO ANO

Poznámka Den, který uživatel měl ve výběru při rezervaci

Tab. 10 - Entita prefer_days Název sloupce

Datový typ

Nenulový

int(10) int(10) varchar(45)

Primární klíč ANO FK NE

id_personal user_id_user Name surname

varchar(45)

NE

ANO

Tel Cosm Hair Pedi Mani visible

varchar(20) smallint(1) smallint(1) smallint(1) smallint(1) smallint(1)

NE NE NE NE NE NE

NE ANO ANO ANO ANO ANO

0 0 0 0 1

priority manualpriority

float tinyint(4)

NE NE

ANO ANO

1 0

Email

varchar(128)

NE

ANO

ANO ANO ANO

Default hodnota 0

Bude zobrazeno v nabídce personálu. Bude zobrazeno v nabídce zákazníkům. Pracovní telefonní číslo

Tab. 11 - Entita personal


Poznámka

Kvůli konzistenci dat nelze personál smazat Nebude se přepočítávat priorita, platí ta, která je zadaná.

Přílohy

Název sloupce Id_event partday

Datový typ int(11) enum('morning', 'midday', 'afternoon')

Primární klíč FK NE

Nenulový ANO ANO

Poznámka Část dne, kterou uživatel měl ve výběru při rezervaci

Tab. 12 - Entita prefer_partday Název sloupce Id_personalfreetime Id_personal open close day dayoff

Datový typ int(11) int(10) time time tinyint(6) tinyint(1)

Primární klíč ANO FK NE NE NE NE

Nenulový ANO ANO ANO ANO ANO ANO

Default hodnota 0 00:00:00 00:00:00 0 0

Tab. 13 - Entita personalfreetime Název sloupce Id_event Id_personal1 Id_personal2 fromDate toDate

Datový typ int(11) int(10) int(10) date date

Primární klíč FK FK FK NE NE

Nenulový ANO NE NE ANO ANO

Poznámka Preferovaný personál Preferovaný personál Preferováno od data Preferováno do data

Tab. 14 - Entita prefer_personal Název sloupce Id_role Id_user Id_role_def

Datový typ int(10) int(10) int(8)

Primární klíč ANO FK FK


Default hodnota

Poznámka

0

Tab. 15 - Entita role Název sloupce Id_role_def value name

Datový typ int(8) int(8) varchar(20)

Primární klíč ANO NE NE


Poznámka Hodnota užívaná v systému

Tab. 16 - Entita role_def Název sloupce Id_statistic fromdate todate type

Datový typ int(11) date date smallint(6)

Primární klíč ANO NE NE NE

Nenulový ANO ANO ANO ANO

Poznámka

Tab. 17 - Entita statistichistory


Přílohy

Název sloupce

Primární klíč ANO FK NE

Nenulový

id_statisticpersonal statistichistory_id_statistic Plan

Datový typ int(11) int(11) int(11)

holiday

int(11)

NE

ANO

worked priority personal_id_personal

int(11) float int(10)

NE NE FK

ANO ANO ANO

ANO ANO ANO

Tab. 18 - Entita statisticpersonal


Poznámka

Délka pracovní doby (min.) Délka dovolené z pracovní doby (min.) Odpracováno (min.) Vypočítaná priorita

Přílohy

B Ukázky obrazovek aplikace

Obr. 25 - Úvodní obrazovka procesu rezervace


Přílohy

Obr. 26 - Historie návštěv


Přílohy

Obr. 27 - Pohled administrátora na dovolenou


Přílohy

Obr. 28 - Pohled na vytíženost personálu


Přílohy

Obr. 29 - Chyby jsou zachytávány již na klientské straně

Obr. 30 - Výsledek špatně zadaných vstupů


Přílohy

Obr. 31 - Pohled do diáře


Přílohy

C Obsah přiloženého CD /data – Testovací data /docs - Javadoc /install – vše nutné k instalaci /databáze - mysql-5.0.26-win32.zip – instalace databáze /properties - salon.properties – konfigurační soubor aplikace /server - jboss-4.0.3RC1.zip – instalace serveru /skripty db - run.bat –automatická instalace struktury databáze - salon.sql – DDL pro MySQL /other –ostatní dokumenty /salon /databáze – DDL pro MYSQL /dist - Salon.war – vlastní aplikace /src -zdrojové soubory /salon-service /dist - salon-rutines.sar – archiv s rutinami /src -zdrojové soubory /text – vlastní text diplomové práce -readme.txt –instalační příručka, obsah CD -index.html –rozšířený abstract


Přílohy

D Instalační příručka Celý vývoj probíhal na PC s operačním systémem Microsoft Windows XP Professional a proto bude i instalační příručka popisovat instalaci na tomto systému. Díky nezávislosti JBoss a MySQL na platformě lze instalaci provést i na jiných operačních systémech. Instalace MySQL Na přiloženém CD je instalační archiv MySQL. Rozbalte a spusťte jej (setup.exe) a následujte tyto kroky:  Zvolte typickou instalaci a cestu, kam se databáze nainstaluje.  Můžete přeskočit registraci (Sign Up).  Zvolte konfigurovat MySQL nyní.  Zvolte Server Machine.  Zvolte Transactional database only.  Pokračujte s předdefinovanými hodnotami až k volbě charakter set a vyberte UTF8.  Dále nastavte heslo pro root připojení. To si zapamatujte, bude potřeba jej nastavit v aplikaci. Do databáze je potřeba vložit její strukturu a základní data. To učiníte nakopírováním obou souborů ze složky (install/skripty db/) do adresáře bin, který je v instalaci MySQL (implicitně c:\Program Files\MySQL\MySQL Server 5.0\bin). Spusťte run.bat a až budete požádáni zadejte zvolené heslo. Instalace JBoss Přednastavenou verzi JBoss serveru přímo pro tuto aplikaci lze instalovat velmi jednoduchým způsobem; nakopírováním archivu (install/server/ jboss-4.0.3RC1.zip) na disk a jeho rozbalením. Vše krom smtp serveru a hesla do databáze je nakonfigurováno. Aplikace bude dostupná na přidělené IP adrese na portu 80 a bude se připojovat k databází na localhost:3306, což je zaručeno instalací MySQL podle předchozího odstavce.  Nastavení smtp serveru se provede v souboru (jboss-4.0.3RC1\server\default\conf\ salon.properties)  Upravení hesla do databáze pro Struts v salon.war/WEB-INF/Struts-config.xml v sekci Data Source Configuration. Pokud nevyužijeme připraveného archivu, je potřeba nakonfigurovat:  Nastavení připojení k databázi, které je využíváno službami SAR (Schedule tasks) viz 8.2.  Nastavení aplikace Salón (salon.properties) – databázový a smtp server, konstanty. Tento soubor se nachází v adresáři install na CD a je potřeba jej umístit do jboss4.0.3RC1\server\default\conf\ On-line rezervační systém 82

Přílohy

 

Nastavení automatických operací (výpočet statistiky, posílání upomínek k návštěvám) v archivu salon-rutines.sar/META-INF/ jboss-service.xml, viz. 8.2. Nakopírováním archivů salon-rutines.sar a salon.war do „deploy“ adresáře příslušné konfigurace.

Podrobněji konfiguraci samotného JBoss serveru popisuje 8.2. Spuštění serveru Nejprve spusťte databázový server (pokud jste postupovali podle návodu, tak již běží). JBoss spustíte souborem run.bat, který je v adresáři jboss-4.0.3RC1\bin\. Předpokladem je nainstalovaná JRE a správně nastavená cesta k ní (classpath).


On-line rezervační systém

Recommend Documents