Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Rezervační komponenta pro informační systém sportovního centra Martin Kolínský
Vedoucí práce: Ing. Jiří Daněček
13. května 2014
Poděkování Na tomto místě bych rád poděkoval vedoucímu práce panu Ing. Jiřímu Daněčkovi za vedení této bakalářské práce a také za poskytnutí cenných rad. Dále bych chtěl poděkovat své rodině, která mě ve studiu vždy podporovala.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 13. května 2014
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Martin Kolínský. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Kolínský, Martin. Rezervační komponenta pro informační systém sportovního centra. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.
Abstrakt Tato bakalářská práce se zabývá návrhem a implementací rezervační komponenty pro informační systém sportovního centra. Práce se nejprve zabývá analýzou existujících řešení. Další část se zabývá návrhem a implementací nové rezervační komponenty. V poslední části této práce je popsáno testování a možnosti dalšího rozvoje. Klíčová slova TypeScript
webová aplikace, rezervační systém, .NET, ASP.NET MVC,
Abstract This bachelor thesis deals with the design and implementation of new reservation component for information system of sport center. First chapter is about analysis of existing solutions. Next chapter is about design and implementation of new reservation component. The last part is about testing and possibilities for future improvements. Keywords web application, reservation system, .NET, ASP.NET MVC, TypeScript
ix
Obsah Úvod
1
1 Rešerše existujících řešení 1.1 Rozdělení rezervačních systémů . . . . . . . . . . . . . . . . . . 1.2 Srovnání existujících systémů . . . . . . . . . . . . . . . . . . .
3 3 4
2 Analýza a návrh 2.1 Rozdělení aplikace . . . . . . 2.2 Uživatelské role . . . . . . . . 2.3 Případy užití . . . . . . . . . 2.4 Stavový diagram rezervace . . 2.5 Návrh uživatelského rozhraní
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
11 11 12 14 18 19
3 Použité technologie 23 3.1 Klientská část . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Serverová část . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4 Realizace 33 4.1 Informační systém PLC . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Implementace rezervační komponenty . . . . . . . . . . . . . . 36 5 Testování 45 5.1 Testovací scénáře . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2 Výsledek testování . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3 Možnosti řešení nedostatků . . . . . . . . . . . . . . . . . . . . 46 Závěr
47
Literatura
49
A Seznam použitých zkratek
51 xi
B Obsah přiloženého CD
53
xii
Seznam obrázků 1.1 1.2 1.3
Kalendář hromadných cvičení a lekcí . . . . . . . . . . . . . . . . . Rezervační systém Rezervačník . . . . . . . . . . . . . . . . . . . . Rezervační systém CLUBSPIRE . . . . . . . . . . . . . . . . . . .
2.1 2.2 2.3 2.4 2.5 2.6 2.7
Dědičnost uživatelských rolí . . . . . . . . . . . . . Diagram případu užití pro roli Anonymní uživatel Diagram případu užití pro roli Zákazník . . . . . . Diagram případu užití pro roli Zákazník . . . . . . Stavový diagram rezervací . . . . . . . . . . . . . . Wireframe hlavní obrazovky zaměstnanecké sekce . Kalendář obsazenosti . . . . . . . . . . . . . . . . .
. . . . . . .
12 14 16 17 18 19 20
3.1 3.2 3.3 3.4 3.5 3.6 3.7
Ukázka překladu Less scriptu (vlevo) na CSS (vpravo) . . . . . . . Ukázka překladu TypeScriptového kódu na JavaScript . . . . . . . Ukázka základní deklarace rozhraní pro práce s jQuery . . . . . . . Ukázka dědičnosti v TypeScriptu . . . . . . . . . . . . . . . . . . . Ukázka použití frameworku Knockout . . . . . . . . . . . . . . . . Architektura MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka možností zápisu dotazu pomocí LINQ (oba způsoby jsou ekvivalentní) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka migrační třídy . . . . . . . . . . . . . . . . . . . . . . . . .
24 25 25 26 27 29
3.8 4.1 4.2 4.3 4.4 4.5 4.6 4.7
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Příklad třídy pro konfiguraci generátoru TypeScriptového kódu . . Nastavení pohledů . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram architetury aplikace . . . . . . . . . . . . . . . . . . . . . Model databázových entit rezervační komponenty . . . . . . . . . . Ukázka použití třídy RoleFilter pro omezení přístupu pouze pro uživatele v roli zaměstnance . . . . . . . . . . . . . . . . . . . . . . Diagram tříd používaných pro ukládání otevírací doby . . . . . . . Formát, ve kterém se ukládá otevírací doba . . . . . . . . . . . . .
xiii
7 8 9
30 31 35 35 37 38 40 40 43
Úvod Toto téma jsem si vybral, protože jsem chtěl vytvořit rezervační systém, který by byl uživatelsky přívětivý a zároveň dostupný i pro menší sportovní centra. Myslím si, že evidence rezervací je problém, který řeší téměř každé sportovní centrum. V první části mojí bakalářské práce provedu rešerši několika existujících řešení, poté navrhnu nový rezervační systém, který nakonec implementuji. Nový rezervační systém bude implementován jako komponenta pro informační systém PLC, který jsme s kolegou J. Hylmarem navrhli a implementovali pro potřeby našich bakalářských prací. V závěru práce popíši výsledek uživatelského testování a možnosti dalšího rozšíření. Cílem této práce je analyzovat existující řešení rezervačních systémů. Na základě analýzy navrhnout a implementovat nový rezervační systém jako komponentu informačního systémů PLC.
1
Kapitola
Rešerše existujících řešení 1.1
Rozdělení rezervačních systémů
Při návštěvách různých sportovních center jsem se setkal s několika způsoby evidence rezervací. Používané systémy jsem rozdělil na: • Papírovou evidenci • Kancelářský software • Specializovaný software
1.1.1
Papírová evidence
Nejjednodušší a nejlevnější způsob řešení problému rezervací je papírová evidence. Tento způsob nevyžaduje investice do hardwaru, softwaru ani připojení sportovního centra k internetu. Není potřeba nic instalovat ani nastavovat, pouze stačí vzít papír a tužku a systém je připravený. Použití tohoto způsobu však přináší řadu nevýhod: • Nevylučuje chyby způsobené obsluhou. • Pro větší a navštěvovanější sportovní centra se systém stává méně přehledným. • Neposkytuje žádné statistiky o návštěvnosti. • Nové rezervace lze přijímat pouze osobně, telefonicky nebo emailem.
1.1.2
Kancelářský software
Kancelářský software má oproti papírové evidenci vyšší pořizovací náklady, ale může částečně vyřešit některé problémy. Při vhodném použití může poskytovat jednoduché statistiky a zlepšit přehlednost. Chyby způsobené obsluhou neřeší a ani neposkytuje více možností přijímání nových rezervací. 3
1
1. Rešerše existujících řešení
1.1.3
Specializovaný software
V dnešní době nejběžnějším řešením evidence rezervací je specializovaný software. Existuje mnoho komerčních systémů, které úplně řeší evidenci rezervací a poskytují i další užitečné funkce. Hlavními nevýhodami specializovaného softwaru jsou pořizovací a provozní náklady. Specializovaný software lze dále rozdělit podle technologií na: • Desktopové aplikace • Webové aplikace Webové aplikace mají oproti desktopovým obrovskou výhodu. Zákazník může zobrazit obsazenost sportovního centra a zadat novou rezervaci pomocí webové aplikace. Z tohoto důvodu jsou webové aplikace nejběžnějším řešením evidence rezervací. V této práci se budu dále zabývat pouze specializovanými webovými aplikacemi.
1.2
Srovnání existujících systémů
Na základě analýzy rezervačních systémů JDEME NA TO, Rezervačník, Bizzy a CLUBSPIRE jsem vybral několik funkcí, které považují za důležité. Vybrané funkce nejprve popíši a následně srovnám analyzované systémy.
1.2.1
Definice pojmů
V této části uvedu několik pojmů, které budu dále v práci používat. 1.2.1.1
Místnost
Místnost je fyzická místnost sportovního centra, kterou je možné rezervovat pro nějakou aktivitu. Například tělocvična nebo tenisový kurt. 1.2.1.2
Aktivita
Aktivita je druh činnosti, pro kterou je možné rezervovat místnost. Aktivity jsem rozdělil na: • Soukromé aktivity – rezervace soukromé aktivity mohou vytvářet pouze uživatelé s oprávněním, například pro aktivitu spinning mohou rezervaci vytvořit pouze zaměstnanci sportovního centra. • Veřejné aktivity – rezervace veřejné aktivity může vytvářet kdokoliv, například zákazník rezervuje tenis (aktivita: tenis, místnost: kurt 1). 4
1.2. Srovnání existujících systémů 1.2.1.3
Rezervace
Rezervace je rezervovaná místnost pro určitou aktivitu v určitém časovém rozmezí. Rezervace jsem rozdělil na: • Soukromé rezervace – rezervace, ke které se nemohou připojovat další zákazníci, např: soukromá rezervace tenisu nebo squashe. • Veřejné rezervace – rezervace, ke které se mohou připojovat další zákazníci, většinou se jedná o hromadné aktivity jako je spinning, alpinning atd., kdy trenér nebo majitel sportovního centra rezervaci založí a zákazníci se poté k rezervaci připojují.
1.2.2
Srovnávané funkce rezervačních systémů
V této části popíšu několik funkcí, které budu u analyzovaných systémů srovnávat. 1.2.2.1
Kontrola docházky a storno poplatky
Problém s nevyzvednutými rezervacemi muší řešit každé sportovní centrum, a proto je vhodné, aby tento problém řešil i rezervační systém. Existuje několik způsobů, jak tento problém řešit . . . Neověřené zákaznické účty jsou pro zákazníky pohodlnější (nemusí sportovní centrum navštívit kvůli ověření totožnosti). Zákazníkům nic nebrání po nevyzvednuté rezervaci vytvořit si nový účet, se kterým se mohou vyhnout odhalení. Ověřené účty problém nevyzvednutých rezervací téměř vyřeší, ale nejsou tolik pohodlné pro zákazníky (ověřování totožnosti). Při nevyzvednuté rezervaci si zákazník nemůže vytvořit nový účet a při příští návštěvě bude určitě odhalen. 1.2.2.2
Multifunkční místnosti
Systém musí umožňovat vytvořit místnosti, ve kterých lze souběžně provozovat různý počet rozdílných aktivit a zamezovat případným kolizím. Například multifunkční hala, kterou lze použít jako jeden tenisový kurt nebo dva badmintonové kurty. Pokud někdo rezervuje jeden badmintonový kurt, systém musí zablokovat i tenisový kurt. 1.2.2.3
Časové omezení aktivit
Systém umožňuje nastavit každé aktivitě omezení, kdy ji lze rezervovat. Omezení jsem rozdělil na: • Denní omezení – umožňuje omezit možnost rezervace na vybrané hodiny. 5
1. Rešerše existujících řešení • Roční omezení – umožňuje omezit možnost rezervace pouze na vybrané dny/měsíce. 1.2.2.4
Časové slevy
Možnost nastavení slevy, která platí pouze po určitou denní dobu. Například pokud nemá sportoviště v ranních hodinách obsazené tenisové kurty, může nastavit na tuto denní dobu slevu. 1.2.2.5
Schvalování rezervací
Některá sportovní centra mohou vyžadovat pro některé aktivity nebo místnosti ruční potvrzování rezervací zaměstnancem. 1.2.2.6
Oprávnění uživatelů
Každé větší sportovní centrum vyžaduje nějakou možnost omezení oprávnění svých zaměstnanců. Systém by měl umožňovat definovat uživatelské role a pro ně definovat povolené akce. 1.2.2.7
Automatické odesílání statistik
Systém umožňuje definovat automatické odesílání souhrnných statistik. V nastavení je umožněno definovat, jakým způsobem se statistiky odešlou ( např. sms nebo email) a jak často se budou odesílat (např. jednou za den). 1.2.2.8
Možnost náhradníků
Pokud je některý termín obsazen, systém umožní případnému zájemci přihlásit se jako náhradník. Pokud zákazník, pro kterého byl termín původně rezervován, svoji rezervaci zruší, systém automaticky rezervuje termín pro zákazníka, který byl přihlášen jako náhradník a informuje ho o tom prostřednictvím sms zprávy nebo emailu.
1.2.3
Analýza rezervačních systémů
V následující části srovnám několik existujících rezervačních systémů. 1.2.3.1
JDEME NA TO
Rezervační systém JDEME NA TO je moderní webová aplikace, která neřeší pouze rezervace, ale také další důležité problémy. Prodejní modul zajišťuje rychlou a efektivní obsluhu zákazníků a také řeší evidenci skladu. Systém zaznamenává historii rezervací a prodejů a poskytuje majiteli sportovního centra důležité statistiky. Samozřejmostí je podpora zákaznických karet. Systém je dostupný v české a anglické lokalizaci. [9] 6
1.2. Srovnání existujících systémů Systém obsahuje tři druhy kalendářů. Pro hromadné aktivity „kalendář hromadných cvičení a lekcí“ a pro individuální aktivity „denní vertikální kalendář“ a „denní horizontální kalendář“. [9]
Obrázek 1.1: Kalendář hromadných cvičení a lekcí Pro zákazníky je připravena i mobilní aplikace, která umožňuje rychlé rezervace prostřednictvím mobilního telefonu. Aplikace umožňuje lokalizovat sportovní centrum prostřednictvím GPS. [9] Systém lze zakoupit ve třech variantách. Nejlevnější varianta stojí 7 900 Kč bez DPH a dále se již neplatí žádné měsíční poplatky. Rozdíl mezi jednotlivými variantami je převážně v technické podpoře a míře poskytnutých školení. Žádná z variant nemá omezené množství poskytovaných aktivit, místností ani počtu vytvořených rezervací. [9] 1.2.3.2
Rezervačník
Rezervační systém Rezervačník se zaměřuje zejména na squashová, tenisová, badmintonová a volejbalová centra, sportovní haly nebo kuželny a bowlingová centra. Systém řeší primárně problém rezervací, a proto neobsahuje další moduly. [11] Systém je řešený formou webové aplikace a pro jeho provozování stačí pouze běžný webový prohlížeč. O hostování systému se stará výrobce systému, a proto není nutné řešit zálohování a aktualizace. [11] Cena systému není pevně nastavena, ale je zvolen model provizí. Prvních 50 rezervací je každý měsíc zdarma, ale z dalších se již platí poplatek. Poplatek 7
1. Rešerše existujících řešení
Obrázek 1.2: Rezervační systém Rezervačník
začíná na 1,50% z ceny rezervace a s přibývajícím množstvím rezervací klesá až na 0,25% z ceny rezervace. [11]
8
1.2. Srovnání existujících systémů 1.2.3.3
CLUBSPIRE
Systém CLUBSPIRE není zaměřený pouze na sportovní centra, ale je také vhodný pro další zařízení jako například: obchody, ubytovací zařízení, restaurace, ski areály, aquaparky, golfové kluby, mateřské školky a mnoho dalších. [10]
Obrázek 1.3: Rezervační systém CLUBSPIRE Systém existuje v několika verzích a skládá se z mnoha modulů. [10] Rezervační modul dokáže spravovat neomezené množství hřišť a areálů, a proto je vhodný pro sportovní centra všech velikostí. Důraz je na intuitivní a ergonomické grafické rozhraní, díky kterému je tvorba nových rezervací nebo odbavení klienta s rezervací velmi rychlé. Maximální využití kapacity zajišťuje systém náhradníků s automatickým upozorňováním emailem nebo SMS. [10]
9
Název funkce Kontrola docházky a storno poplatky Multifunkční místnosti Časové omezení aktivit - denní Časové omezení aktivit - roční Časové slevy Schvalování rezervací Oprávnění uživatelů Automatické odesílání statistik Možnost náhradníků
10 x
CLUBSPIRE x x x x x x x x
Rezervačník x x
1.2.4
x
JDEME NA TO x x x
1. Rešerše existujících řešení
Tabulka srovnání analyzovaných systémů
Následující tabulka srovnává funkce předchozích systémů.
Kapitola
Analýza a návrh V této části práce popíši návrh nové rezervační komponenty. Nejprve popíší způsob rozdělení komponenty na jednotlivé části, poté uživatelské role a případy užití, stavový diagram rezervací a nakonec návrh uživatelského rozhraní.
2.1
Rozdělení aplikace
Komponenta je rozdělena do několika částí s rozdílným určením.
2.1.1
Zákaznická část
Zaměstnanecká část je výchozí částí aplikace, která je určena zákazníkům sportovního centra. Do této části se uživatelé dostanou po vstupu do systému. Uživatelé v této části mohou: • vytvořit nový zákaznický účet • přihlásit se do systému • prohlížet kalendář s aktuálním obsazením sportovního centra • vytvářet a spravovat svoje rezervace • přejít do zaměstnanecké nebo administrační části
2.1.2
Zaměstnanecká část
Zaměstnanecká část je částí aplikace, která je určena pro zaměstnance sportovního centra (např. recepční). Uživatelé v této části mohou: • prohlížet kalendář s aktuálním obsazením sportovního centra • vytvářet anonymní rezervace 11
2
2. Analýza a návrh • spravovat veškeré rezervace • zadávat výluky • zobrazovat statistiky
2.1.3
Administrační část
Tato část aplikace je určena pro nastavování rezervačního systému. Uživatelé v této části mohou: • spravovat aktivity a místnosti • nastavovat otevírací dobu sportovního centra, aktivit a místností • spravovat oprávnění uživatelů
2.2
Uživatelské role
Ne každý uživatel může přistupovat do všech částí systému, a proto je nutné rozlišovat uživatelské role, které určují, jaké části jsou pro koho přístupné. Systém umožňuje přiřadit jednomu uživateli více rolí.
Obrázek 2.1: Dědičnost uživatelských rolí
12
2.2. Uživatelské role
2.2.1
Anonymní uživatel
Je to uživatel, který nebyl autentizován a má pouze velice omezené možnosti práce s aplikací. Může přistupovat pouze do zákaznické části aplikace, kde může procházet dostupné aktivity a zobrazit jejich kalendář, na kterém jsou zobrazeny volné termíny. Pro další práci s aplikací se musí zaregistrovat a přihlásit.
2.2.2
Zákazník
Jedná se o základní uživatelskou roli, kterou dostane každý, kdo se do systému zaregistruje. Stejně jako anonymní uživatel může přistupovat pouze do zákaznické sekce systému, kde navíc může vytvářet nové rezervace nebo spravovat ty, které dříve vytvořil.
2.2.3
Zaměstnanec
Tato role je určena pro zaměstnance sportovního centra, kteří pracují např. na recepci. Uživatel v roli zaměstnanec může přistupovat do zaměstnanecké sekce, kde může spravovat veškeré rezervace v systému a v případě potřeby může zrušit rezervace jiných uživatelů nebo jejich majitele kontaktovat. Dále může vytvářet anonymní rezervace pro návštěvníky, kteří rezervaci provádí osobně, telefonicky nebo emailem.
2.2.4
Majitel
Role určená pro vedoucího nebo majitele sportovního centra, který má přístup ke všem funkcím zaměstnanecké sekce.
2.2.5
Administrátor
Role pro správce sytému, který má přístup do administrační sekce. Uživatel v této roli má přístup ke všem funkcím administrační sekce.
13
2. Analýza a návrh
2.3
Případy užití
Následující sekce obsahuje případy užití rezervační komponenty, rozdělené podle jednotlivých rolí v systému.
2.3.1
Anonymní uživatel
Obrázek 2.2: Diagram případu užití pro roli Anonymní uživatel
1. Přihlášení do systému Systém umožňuje uživatelům, kteří již mají vytvořený uživatelský účet, opětovné přihlášení do systému. 2. Vytvoření zákaznického účtu Systém umožňuje každému návštěvníkovi vytvořit uživatelský účet, který je nutný pro vytváření nových rezervací. 14
2.3. Případy užití 3. Zobrazení kalendáře obsazenosti Systém umožňuje zobrazit kalendář s aktuálním stavem obsazenosti. Po vybrání požadované aktivity a termínu systém zobrazí kalendář s volnými termíny. 4. Vytvoření nové rezervace Systém uživateli umožňuje vytvořit novou rezervaci. Uživatel se musí nacházet v kalendáři obsazenosti, kde vybere požadovanou aktivitu a volný termín. Po vybrání zadá požadovanou délku (u soukromá rezervace) nebo požadovaný počet míst (u veřejné rezervace). Nakonec odešle požadavek na rezervaci. Po potvrzení nebo zamítnutí rezervace zaměstnancem sportovního centra odešle systém uživateli email s rozhodnutím (potvrzeno nebo zrušeno). 5. Procházení vlastních rezervací Systém uživateli umožňuje procházet vlastní rezervace. Uživateli jsou zobrazeny budoucí i minulé rezervace. 6. Zrušení existující rezervace Systém uživateli umožňuje zrušit jeho budoucí rezervace. Pokud se uživatel pokusí zrušit rezervaci, která začíná za kratší dobu než je nastavený limit pro zrušení rezervace, systém akci znemožní a informuje uživatele.
15
2. Analýza a návrh
2.3.2
Zaměstnanec a majitel
Obrázek 2.3: Diagram případu užití pro roli Zákazník
1. Zobrazení detailního kalendáře obsazenosti Systém umožňuje uživateli zobrazit detailní kalendář se všemi rezervacemi včetně jejich detailů. 2. Vytvoření anonymní rezervace Systém umožňuje uživateli po vybrání požadované aktivity a času v detailním kalendáři obsazenosti vytvořit anonymní rezervaci. Takto vytvořená rezervace je rovnou potvrzená a osoba, pro kterou je rezervace určena, ji může zrušit pouze kontaktováním zaměstnance. 3. Zobrazení nebo zamítnutí požadavků na rezervaci Systém umožňuje uživateli potvrdit nebo zamítnout požadavky na rezervaci. Po potvrzení nebo zamítnutí je zákazník, který požadavek odeslal, informován emailem o výsledku. 16
2.3. Případy užití 4. Zadávání výluky Systém umožnuje zadat výluku v provozu sportovního centra. Uživatel určí požadovaný den a časový rozsah výluky. Pokud v danou dobu existují v systému nějaké rezervace, systém je automaticky zruší a jejich majitele informuje emailem. 5. Zobrazení statistik Systém uživateli umožňuje zobrazit několik statistik: • poměr vyzvednutých a nevyzvednutých rezervací • průměrný počet rezervací jednotlivých aktivit za den
2.3.3
Administrátor
Obrázek 2.4: Diagram případu užití pro roli Zákazník
1. Správa aktivit Systém umožňuje vytvářet, upravovat a mazat aktivity. 2. Správa místností Systém umožňuje vytvářet, upravovat a mazat místnosti. 3. Nastavení využitelnosti místnosti Systém umožňuje nastavit pro každou místnost seznam aktivit, pro které je využitelná. U každého záznamu uživatel specifikuje kapacitu při využití místnosti pro danou aktivitu. 17
2. Analýza a návrh 4. Nastavení otevírací doby Systém umožňuje nastavit jak otevírací dobu celého sportovního centra, tak také otevírací dobu pro jednotlivé místnosti a aktivity. 5. Správa oprávnění uživatelů Systém umožňuje procházet uživatele v systému a měnit jejich role.
2.4
Stavový diagram rezervace
Následující diagram zobrazuje stavy, v jakých se mohou jednotlivé rezervace nacházet.
Obrázek 2.5: Stavový diagram rezervací Rezervace vzniká zadáním požadavku zákazníkem nebo zaměstnancem a přejde do stavu Čekání na potvrzení rezervace. V případě, že se jedná o anonymní rezervaci vytvořenou zaměstnancem, systém automaticky rezervaci potvrdí a přejde do stavu Rezervace potvrzena. Pokud se jedná o rezervaci, kterou zadává zákazník, je nutné, aby zaměstnanec rezervaci zamítl (přejde do stavu Rezervace zamítnuta) nebo potvrdil (přejde do stavu Rezervace potvrzena). Po potvrzení je majitel rezervace informován emailem. Po potvrzení vyzvednutí rezervace zaměstnancem, rezervace přejde do stavu Rezervace vyzvednuta. V případě, že se zákazník nedostaví a rezervaci nevyzvedne, systém automaticky změní stav rezervace na Rezervace nevyzvednuta. Pokud zákazník nebo systém rezervací zruší, rezervace přejde do stavu Rezervace zrušena. 18
2.5. Návrh uživatelského rozhraní
2.5
Návrh uživatelského rozhraní
V této sekci popíši návrh uživatelského rozhraní pro jednotlivé sekce aplikace. Nejprve bude popsána zaměstnanecká část, poté administrační a nakonec zákaznická. Na konci sekce popíši kalendář obsazenosti, který je použit v zákaznické a zaměstnanecké sekci.
2.5.1
Zaměstnanecká část
Při návrhu uživatelského rozhraní pro zaměstnance bylo hlavním cílem, aby práce v této části byla co nejefektivnější. Snažil jsem se, aby všechny funkce, které bude obsluha při práci běžně používat, byly na jedné stránce a zaměstnanec věděl o všem důležitém bez nutnosti procházet různé sekce aplikace.
Obrázek 2.6: Wireframe hlavní obrazovky zaměstnanecké sekce Na obrázku 2.6 je zobrazen návrh hlavní obrazovky uživatelského rozhraní zaměstnanecké sekce. Rozhraní se skládá z následujících částí: • V horní části levého panelu (žlutá barva) je zobrazen seznam aktivit. Při výběru některé z nich se zobrazí kalendář obsazenosti pro vybranou aktivitu. • Ve spodní části levého panelu (červená barva) se nachází panel obsahující upozornění na nové rezervace. Tento panel se zobrazuje pouze, pokud existuje nějaká rezervace, kterou je nutné potvrdit nebo zamítnout. Při kliknutí dojde k zobrazení kalendáře obsazenosti pro první nepotvrzenou rezervaci. Opakovaným kliknutím může obsluha přecházet na další nové rezervace. • Levý panel nad kalendářem obsazenosti (zelená barva) zobrazuje aktivitu a den, pro který je aktuálně zobrazen kalendář obsazenosti. 19
2. Analýza a návrh • Pravý panel nad kalendářem obsazenosti (světle modrá barva) zobrazuje tlačítka pro rychlou změnu kalendáře obsazenosti na dny následujícího týdne. Dále obsahuje ikonu kalendáře, u kterého se po najetí myší zobrazí kalendář pro výběr jiného dne.
2.5.2
Administrační sekce
Rozhraní administrační sekce se skládá z několika tabulek a editačních formulářů, které nejsou ničím zajímavé, a proto nebudu rozhraní této sekce podrobněji popisovat.
2.5.3
Zákaznická sekce
Zákaznické sekce je rozdělena do dvou podstránek. První z nich je stránka s výpisem zákazníkových rezervací a druhá je stránka s kalendářem obsazenosti. Stránka s výpisem zákazníkových rezervací obsahuje tabulku, ve které jsou zobrazeny jednotlivé rezervace. Pokud je danou rezervaci možné zrušit, je v příslušném řádku zobrazeno tlačítko pro zrušení rezervace. Stránka s kalendářem obsazenosti vychází z návrhu zaměstnanecké sekce (obrázek 2.6). Jediný rozdíl je, že v zákaznické sekci není zobrazen panel nových rezervací (červená barva).
2.5.4
Kalendář obsazenosti
Obrázek 2.7: Kalendář obsazenosti 20
2.5. Návrh uživatelského rozhraní Kalendář obsazenosti je velká tabulka. Jednotlivé sloupce tvoří místa v místnostech (např. kurt, dráha, ...), která lze pro vybranou aktivitu rezervovat. Řádky zobrazují časové úseky. V buňkách tabulky se zobrazují jednotlivé rezervace. Podrobnost zobrazených informací se liší podle sekce, ve které je kalendář obsazenosti použit. Po kliknutí na prázdnou buňku je zobrazen formulář pro zadání nové rezervace. Po kliknutí na buňku existující rezervace je zobrazen editační formulář, který se liší podle sekce, ve které je kalendář použit. V zákaznické sekci je zobrazen pouze, pokud se jedná o vlastní rezervaci a obsahuje tlačítko pro zrušení. V zaměstnanecké sekci je zobrazen detail rezervace.
21
Kapitola
Použité technologie Tato kapitola obsahuje popis použitých technologii a frameworků. Technologie jsou rozděleny podle použití na straně klienta nebo serveru.
3.1
Klientská část
V této části postupně popíši použité technologie na straně klienta.
3.1.1
HTML
Základem webové aplikace je technologie HTML. HTML je značkovací jazyk, kterým se definuje struktura webových dokumentů. Pro definici struktury dokumentu se využívají značky (tagy), které popisují obsah dokumentu. Pomocí tagů lze do dokumentu vložit obrázky, tabulky nebo také vytvářet různé formuláře. Dříve sloužilo HTML i pro formátování a stylování dokumentu, ale k tomuto účelu dnes již slouží kaskádové styly (CSS). [4]
3.1.2
CSS a Less
CSS (Kaskádové styly) je jazyk pro definici vzhledu dokumentů. Pomocí CSS lze definovat vzhled nejen HTML dokumentů, ale také XHTML nebo XML [2]. Použití CSS přináší mnoho výhod: • Znovu použitelnost - styly uložené v externích CSS souborech lze jednoduše vkládat do různých HTML dokumentů • Jednoduchá údržba - při nutnosti změnit vzhled dokumentu stačí upravit CSS soubor bez nutnosti zásahů do HTML dokumentů • Možnosti cachování - externí CSS dokumenty lze jednoduše ukládat do cache paměti webového prohlížeče a tím dosáhnout rychlejšího načítání 23
3
3. Použité technologie Less je CSS pre-procesor rozšiřující možnosti jazyka CSS [7]. Několik nejdůležitějších rozšíření: • proměnné - možnost definovat proměnnou a použít ji na více místech. Např. při opakovaném použití jedné barvy je možné na začátku souboru vytvořit proměnnou, do které se barva přiřadí. Poté již v pravidlech můžeme používat pouze vytvořenou proměnnou a v případě změny barvy stačí měnit hodnotu pouze na jediném místě. [7] • mixins - umožňuje vložit vlastnosti jednoho pravidla do jiného. Např. aby v případě potřeby mělo více pravidel nějakou část vlastností stejných, můžeme vytvořit nové pravidlo se společnými vlastnostmi a to poté vložit do původních pravidel. [7]
Obrázek 3.1: Ukázka překladu Less scriptu (vlevo) na CSS (vpravo) (zdroj: http://lesscss.org)
3.1.3
TypeScript
V současné době je prakticky jedinou možností skriptování na straně klienta (webový prohlížeč) použití JavaScriptu, který má však několik vlastností, které nejsou příliš vhodné pro vývoj větších webových aplikací. TypeScript je pouze rozšíření JavaScriptu. Při kompilaci se překládá na čistý JavaScript, díky čemuž je aplikace napsaná v TypeScriptu spustitelná ve všech stávajících webových prohlížečích s podporou JavaScriptu. [12]
24
3.1. Klientská část
Obrázek 3.2: Ukázka překladu TypeScriptového kódu na JavaScript (zdroj: http://www.typescriptlang.org/Playground)
3.1.3.1
Deklarační soubory
Deklarační soubory umožňují definovat rozhraní pro částí kódu napsaného v JavaScriptu (například pro použití knihovny jQuery je nutné vložit deklaraci jejího rozhraní). Deklarační soubory pro většinu běžně používaných JavaScriptových knihoven jsou dostupné na https://github.com/borisyankov/DefinitelyTyped. [13]
Obrázek 3.3: Ukázka základní deklarace rozhraní pro práce s jQuery (zdroj: Specifikace TypeScriptu [13])
25
3. Použité technologie 3.1.3.2
Typové anotace
Typové anotace slouží ke specifikaci typu parametru nebo proměnné a umožňují typovou kontrolu již během kompilace. Uvádějí se za deklarací proměnné (var cislo: number;) typem parametru nebo před tělem funkce (function Diff(a: number, b: number) : number { return a - b; }). Primitivní datové typy jsou: string, number, boolean, void a null [13]. Dále TypeScript obsahuje dynamický datový typ any a podporuje výčtové datové typy. Typové anotace není nutné uvádět. V případě, že není anotace uvedena, použije se dynamické typování JavaScriptu. [12] 3.1.3.3
Podpora OOP
TypeScript umožňuje: • vytvářet třídy (class), rozhraní (interface), výčtové typy(enum) a moduly (module) • podporuje modifikátory přístupu public a private, modifikátor protected není podporován • podporuje generické typy a funkce
Obrázek 3.4: Ukázka dědičnosti v TypeScriptu V mojí práci bude TypeScript využit pro scriptování složitějších klientských formulářů a tvorbu rezervačního kalendáře. 26
3.1. Klientská část
3.1.4
jQuery
jQuery je JavaScriptová knihovna usnadňující psaní JavaScriptového kódu. Řeší možnost jednoduchého výběru DOM elementů, události, AJAX, parsování JSON a mnoho dalšího. Knihovnu jQuery podporují všechny běžné webové prohlížeče a je šířena pod licencí MIT. [5]
3.1.5
Knockout
JavaScriptový framework Knockout umožňuje vytvářet dynamické JavaScriptové aplikace vzorem MVVM (Model-View-View Model). Jedná se o open source framework pod licencí MIT, který podporují všechny běžné webové prohlížeče. [6] Hlavní vlastnosti tohoto frameworku jsou: • Jednoduché propojení DOM elementů s modelem použitím výstižné a čitelné syntaxe [6] • Automatická obnova uživatelského rozhraní při změně datového modelu [6]
Obrázek 3.5: Ukázka použití frameworku Knockout (zdroj: http://learn.knockoutjs.com) Při implementaci komponenty bude framework Knockout použit pro vytvoření rezervačního kalendáře a složitějších formulářů. 27
3. Použité technologie
3.2
Serverová část
V této části popíši technologie, které jsem použil na straně serveru.
3.2.1
.NET Framework a ASP.NET
.NET Framework je softwarová platforma, na které lze vyvíjet různé druhy aplikací. Podporuje například vývoj desktopových, webových nebo mobilních aplikací. [8] Obsahuje velké množství knihoven pro usnadnění vývoje a také běhové prostředí, které umožňuje spuštění aplikací napsaných v .NET Frameworku. Pro vývoj aplikací lze využít vývojové prostředí Visual Studio. Pro vývoj aplikací lze použít několik programovacích jazyku. Jedná se například o programovací jazyk C# nebo VB.NET. [8] Pro vývoj webových aplikací obsahuje .NET Framework techologii ASP.NET. ASP.NET umožňuje tvorbu webových aplikací několika způsoby. První z nich je použitím technologie ASP.NET WebForms, která má za cíl umožnit vývoj webových aplikací podobným způsobem jako se vyvíjí desktopové aplikace. Časem přibila další možnost jak pomocí ASP.NET webové aplikace vyvíjet. Jedná se o ASP.NET MVC. [1]
3.2.2
ASP.NET MVC
ASP.NET MVC je open source framework pro tvorbu webových aplikací, který je vyvíjen společností Microsoft. ASP.NET MVC framework rozšiřuje ASP.NET o možnost tvorby aplikací architekturou MVC. [1] Architektura MVC rozděluje aplikaci do tří nezávislých částí. Cílem je, aby změna některé z nich měla co nejmenší vliv na ostatní. Tato vlastnost je velmi důležitá pří vývoji rozsáhlejších aplikací. [1] • Model Model je vrstva MVC, obsahující datové struktury a veškerou validační a aplikační logiku. Model je nezávislý od pohledů a řadičů a musí fungovat samostatně. [1] • Pohled (View) Pohled má za úkol transformovat data, která dostane z řadiče na výstup, který se zobrazí uživateli. Pohled by neměl obsahovat aplikační ani validační logiku, ale pouze převést vstupní data na výstup, se kterým může uživatel pracovat. [1] • Řadič (Controller) Řadič se stará o zpracování požadavků uživatele. Pracuje s modelem, ve kterém spustí požadovanou aplikační logiku a poté vybere pohled, který se použije pro transformaci výstupu. [1] 28
3.2. Serverová část
Obrázek 3.6: Architektura MVC (zdroj: http://www.asp.net) V ASP.NET MVC lze předávat data z řadiče do pohledu pomocí modelu. V případě nutností předání doplňujících dat je možné využít speciální objekt ViewBag, který může předat libovolné množství dalších dat. [1] ASP.NET MVC obsahuje možnost seskupování řadičů, pohledů a modelů, nazvanou oblast (area). Tato vlastnost zjednodušuje tvorbu modulárních aplikací. [1]
29
3. Použité technologie
3.2.3
Entity Framework
Entity Framework je open source ORM (object-relational mapping) od společnosti Microsoft. Je součástí .NET Frameworku od verze 3.5 a aktuálně se nachází ve verzi 6.0. [3] Stejně jako jiné ORM je cílem Entity Frameworku poskytnout vývojáři možnosti práce s databází bez nutnosti psát SQL dotazy. Entity Framework umožňuje pracovat s daty pomocí dotazovacího jazyku LINQ (Language Integrated Query), který je součástí .NET Frameworku. Výhodou tohoto přístupu je nezávislost na použitém databázovém systému a v případě potřeby není problém databázový systém změnit. [3]
Obrázek 3.7: Ukázka možností zápisu dotazu pomocí LINQ (oba způsoby jsou ekvivalentní) Pro práci s databází je nutné vytvořit datový model, na základě kterého Entity Framework může generovat potřebné dotazy. V Entity Frameworku existuje několik možností, jak datový model vytvořit. 3.2.3.1
Database first
Metoda database first je vhodná, pokud je již databáze vytvořena nebo ji chceme vytvořit klasicky pomocí jazyka SQL. Entity framework na základě existující databáze vygeneruje třídy entit, které odpovídají existujícím databázovým tabulkám. [3] 3.2.3.2
Model first
Při použití metody model first je databáze navržena v návrhovém nástroji, který je součástí Entity Frameworku. Na základě navrženého modelu jsou vytvořeny tabulky v databázi. [3]
30
3.2. Serverová část 3.2.3.3
Code first
Code first je nejnovější metoda tvorby databázového modelu. Tato metoda byla přidána ve verzi 4.1 a je velmi oblíbená. Vývojář nepoužívá žádný návrhový nástroj, který by kód generoval, ale píše kód entit ručně a má proto úplnou kontrolu nad výsledným kódem. Entity framework vytvoří databázové tabulky podle vytvořených entitních tříd. [3] Další výhodou code first jsou migrace. Migrace zajišťují změny databázových tabulek při změně entitních tříd. Migrace je speciální třída, která obsahuje kód pro změnu databázových tabulek z předchozí verze na aktuální a zároveň kód pro změnu do původního stavu. Díky tomu je zajištěné verzování databáze, a pokud je nutné se při vývoji vrátit na starší verzi aplikace, není problém vrátit do původního stavu i databázové tabulky. [3]
Obrázek 3.8: Ukázka migrační třídy Díky předchozím výhodám metody code first jsem ji nakonec pro implementaci datové vrstvy zvolil.
31
Kapitola
Realizace 4.1
Informační systém PLC
Společně s kolegou J. Hylmarem jsme pro potřeby našich bakalářských prací navrhli a implementovali základní systém, který bude sloužit jako společný základ pro jednotlivé komponenty. Hlavním cílem bylo vytvořit základní systém, který poskytne sadu rozhraní a tříd pro vývoj jednotlivých komponent. Systém byl navržen tak aby obsahoval pouze nutné funkce, které jsou společné pro všechny komponenty. Systém dále obsahuje šablony a základní funkce pro jednotlivé sekce aplikace (zákaznické, zaměstnanecká a administrační). Systém se skládá z následujících částí: • PLC.Host Je základní ASP.NET aplikace celého systému PLC. Realizován je v ASP.NET MVC 5.1.2 a očekává se, že komponenty budou využívat stejný framework ve stejné verzi. Hlavním úkolem této aplikace je zajistit správné načtení jednotlivých komponent. Obsahuje základní funkce, které jsou společné pro všechny komponenty. Konkrétně se jedná o: – vytváření uživatelských účtů – autentizace uživatelů – správa uživatelských rolí – správa komponent • PLC.ComponentBase Je knihovna obsahující třídy a rozhraní nutné pro implementaci komponenty použitelné v systému PLC. Dále obsahuje pomocné třídy pro 33
4
4. Realizace implementaci datové a doménové vrstvy a také generování TypeScriptového kódu. Použití jednotlivých částí této knihovny bude popsáno v dalších částech práce. • PLC.DomainLayer Je knihovna obsahující doménové objekty reprezentující uživatele, role a komponenty. Dále obsahuje služby pro získávaní předchozích objektů. Pokud je v komponentě potřebné pracovat s uživateli, je nutné přidat referenci na tuto knihovnu. • PLC.DataLayer Je knihovna obsahující základní datovou vrstvu systému. Osahuje datové entity a repozitáře pro práci s uživateli, rolemi a komponentami. Pro implementaci je použit Entity Framework. • PLC.DataLayer.EntityFrameworkBase Je knihovna, která obsahuje pomocné třídy pro práci s Entity Frameworkem. Při použití Entity Frameworku je možné použít třídy z této knihovny pro implementaci repozitářů. • PLC.TypeScriptGenerator Je jednoduchá aplikace určená pro generování TypeScriptového kódu. V zadané DLL knihovně najde všechny řadiče, obsahující akce s atributem TypeScriptGenerator. Pro nalezené řadiče vygeneruje TypeScriptové třídy umožňující volání akcí řadiče. Komunikace probíhá pomocí AJAXu a k přenosu dat je použit formát JSON. Pokud akce vrací nebo očekávají parametr, který není jednoduchým datovým typem, je nutné, aby knihovna komponenty obsahovala konfigurační třídu dědící z třídy GeneratorConfiguration z knihovny PLC.ComponentBase. V konfigurační třídě lze určit namespace, ve kterém se budou generované třídy a rozhraní nacházet a také způsob, jakým bude generován kód pro složené datové typy (příklad jednoduché konfigurační třídy na obrázku 4.1). K dispozici jsou následující módy: – SharedTypeMode.Interface - v tomto módu je pro složený datový typ vygenerováno pouze rozhraní, které je poté nutné ručně implementovat. Rozhraní obsahuje stejné vlastnosti jako původní složený datový typ. – SharedTypeMode.Auto - v tomto módu je pro složený datový typ vygenerována třída, obsahující všechny vlastnosti jako zdrojový datový typ.
4.1.1
Struktura komponenty pro systém PLC
Každá komponenta pro systém PLC se může skládat z jedné a více DLL knihoven. 34
4.1. Informační systém PLC
Obrázek 4.1: Příklad třídy pro konfiguraci generátoru TypeScriptového kódu
Hlavní knihovna komponenty musí obsahovat alespoň jednu oblast. Všechny řadiče, pohledy a modely musí být umístěné v nějaké oblasti. Umístění do oblasti zabrání případným kolizím v pojmenování mezi jednotlivými komponentami. Jediný požadavek na název oblasti je, aby byl jedinečný v rámci celé aplikace a všech komponent. U všech pohledů (soubory *.cshtml), umístěných v komponentě, je nutné nastavit vlastnost Custom Tool na RazorGenerator (zobrazeno na obrázku 4.2). Ve výchozím nastavení nejsou pohledy kompilovány, ale pouze kopírovány jako datové soubory a kompilovány až při spuštění aplikace, což není vhodné pro modulární systém. Změněním této vlastnosti dojde ke generování C# kódu okamžitě a pohled je proto součástí výsledné DLL knihovny. Díky tomu může být komponenta tvořena pouze jedinou DLL knihovnou.
Obrázek 4.2: Nastavení pohledů Hlavní knihovna komponenty musí obsahovat třídu, která implementuje rozhraní IComponent z knihovny PLC.ComponentBase. Metody a vlastnosti, které musí třída implementovat jsou: • string Name { get; } Vlastnost, která vrací název komponenty. 35
4. Realizace • void Install(IContainer container); Tato metoda je volána při inicializaci komponenty a musí provést nastavení nutné pro správný běh komponenty. V parametru metody je předán IoC kontejner, na kterém je možné provést potřebné registrace. • void UpdateLayout(ILayoutConfiguration layoutConfiguration); Tato metoda je volána po provedení metody Install. Použitím metod parametru objektu layoutConfiguration lze: – registrovat oblasti komponenty a nastavovat jejich šablony – vložit CSS nebo JavaScriptové soubory do šablony sekce – vkládat vlastní odkazy do menu sekce
4.2
Implementace rezervační komponenty
V této části práce popíši způsob navržení architektury rezervační komponenty, řešené problémy při implementaci a nakonec způsob propojení s pokladní komponentou.
4.2.1
Architektura rezervační komponenty
Rezervační komponenta je navržena jako třívrstvá aplikace. Jednotlivé vrstvy jsou: • datová vrstva • doménová vrstva • vrstva uživatelského rozhraní 4.2.1.1
Datová vrstva
Datová vrstva poskytuje základní funkce pro práci s daty. Pro každou entitu (objekt, který je třeba uchovávat) obsahuje datová vrstva repozitář, který poskytuje metody pro vkládání, mazání a výběr entit daného typu. Metody pro výběr poskytují možnosti filtrování, řazení a stránkování entit. Většina repozitářů a entit byla implementována pomocí ORM Entity Framework. Z důvodu opakujícího se kódu u repozitářů byla v PLC knihovně PLC.DataLayer.EntityFrameworkBase vytvořena třída EntityFrameworkRepositoryBase, která obsahuje základní implementaci pro všechny potřebné metody. Z této třídy všechny repozitáře, pracující s Entity Frameworkem, dědí a v případě potřeby mohou libovolnou metodu přepsat a upravit její chování podle potřeby. Jediný repozitář, který nevyužívá databázi, je repozitář pro ikony aktivit. Tento repozitář využívá souborový systém. Při inicializaci najde všechny 36
4.2. Implementace rezervační komponenty
Obrázek 4.3: Diagram architetury aplikace
obrázky v příslušném datovém adresáři a v paměti si uchová jejich seznam, který využije při dotazování. Tento repozitář obsahuje pouze metody pro výběr. Přidání nové ikony se provádí vložením obrázku do datového adresáře. Ke každému repozitáři a entitě je definované rozhraní, se kterým může další vrstva pracovat. Tímto způsobem je docíleno oddělení implementace datové vrstvy a v případě nutnosti je jednoduché implementaci změnit. Na obrázku 4.4 je zobrazen model databázových entit rezervační komponenty. Popis jednotlivých entit: • Activity - Entita reprezentující aktivitu. • Room - Entita reprezentující místnost. • ActivityDetail - Entita určující možnosti využití mísnosti. Říká, pro jakou aktivitu s jakou kapacitou lze místnost využít. • OpeningHour - Entita reprezentující otevírací dobu. Otevírací doba se může vztahovat na celé sportovní centrum (vlastnosti Activity a Room jsou nastaveny na hodnotu null), na konkrétní místnost nebo na konkrétní aktivitu. Návrh dále umožňuje vztáhnout otevírací dobu na konkrétní aktivitu v konkrétní místnosti, ale protože jsem nenašel reálnou možnost využití této kombinace, není tato možnost implementována v uživatelském rozhraní. Jelikož není potřebné provádět databázové dotazy, které by filtrovaly podle jiných vlastností, jsou další data ukládána 37
4. Realizace
Obrázek 4.4: Model databázových entit rezervační komponenty
v binárním formátu. Formát uložených dat je rozebrán v sekci Řešené problémy - Otevírací doba. • Reservation - Entita reprezentující rezervaci. Vlastnosti Capacity je využita pouze v případě, že se jedná o veřejnou rezervaci. • ReservationMember - Entita obsahující záznam o účastníkovi veřejné rezervace. Vlastnost Capacity obsahuje počet rezervovaných míst. • Lockout - Entita reprezentující výluku. Výluku lze zadat na celé sportovní centrum (vlastnosti Activity a Room jsou nastaveny na hodnotu null) nebo na jednotlivé místnosti a aktivity. Datová vrstva rezervační komponenty je implementována v knihovně PLC.DataLayer.Reservations. 4.2.1.2
Doménová vrstva
Přístup k doménovým objektům zajišťují služby. Každá služba obsahuje metodu pro vytvoření nového doménového objektu a dále také několik metod pro získávání doménových objektů včetně filtrování, řazení a stránkování. 38
4.2. Implementace rezervační komponenty Tyto metody využívají repozitáře z datové vrstvy pro získání datových entit, které použijí k vytvoření doménových objektů. Stejně jako v případě repozitářů, mohou služby dědit z třídy ServiceBase (obsažena v PLC knihovně PLC.ComponentBase), která obsahuje výchozí implementaci všech potřebných metod. Nejdůležitější částí doménové vrstvy jsou doménové objekty, které reprezentují konkrétní objekty v systému (např. rezervace, mísnost, ...). Doménové objekty obsahují aplikační a validační logiku. Pokud služba dědí z objektu ServiceBase, je nutné, aby doménový objekt implementoval rozhraní IDomainObject, případně dědil z připraveného objektu DomainObjectBase, který obsahuje základní implementaci metod pro ukládání a mazání. Stejně jako u datové vrstvy má každá služba a doménový objekt definováno rozhraní. Tato rozhraní jsou opět využita v další vrstvě ke komunikaci s doménovou vrstvou. Doménová vrstva rezervační komponenty je implementována v knihovně PLC.DomainLayer.Reservations. 4.2.1.3
Vrstva uživatelského rozhraní
Vrstva uživatelského rozhraní byla implementována pomocí frameworku ASP.NET MVC. Pro rezervační kalendář a složitější formuláře byl využit JavaScriptový framework Knockout. Jelikož rezervační komponenta přidává funckionalitu do všech tří sekcí systému (zákaznická, zaměstnanecká a administrační), bylo nutné vytvořit tří ASP.NET MVC oblasti. Každá z nich je určena pro jednu sekci. Vrstva uživatelského rozhraní je implementována v knihovně PLC.Reservations.
4.2.2
Způsob kontroly uživatelské role
Pro omezení přístupu k vybraným řadičům nebo akcím byl využít atribut RoleFilter z knihovny PLC.DomainLayer, který jako parametr přijímá seznam názvů uživatelských rolí. V případě, že uživatel není v žádné z rolí na seznamu, je mu znemožněno akci provést. Při použití atributu na řadič jsou bez dalšího nastavení všechny akce omezeny na určené role. V případě potřeby povolení anonymního přístupu pro některou akci lze využít atribut AllowAnonymous z ASP.NET MVC frameworku.
39
4. Realizace
Obrázek 4.5: Ukázka použití třídy RoleFilter pro omezení přístupu pouze pro uživatele v roli zaměstnance
4.2.3
Řešené problémy
Během implementace jsem narazil na několik složitějších implementačních problémů, které v této části práce podrobněji popíši. 4.2.3.1
Otvírací doba
Nejprve popíši třídy, které jsem vytvořil pro práci s otvírací dobou:
Obrázek 4.6: Diagram tříd používaných pro ukládání otevírací doby
• Třída Time Pro ukládání času obsahuje .NET pouze datový typ Datetime. Tento typ obsahuje spoustu zbytečných informací, které nejsou pro reprezentaci času potřeba. Při ukládání zabere 8 bytů. Z tohoto důvodu jsem se rozhodl pro implementaci vlastního typu pro reprezentaci času, který bude obsahovat pouze potřebné vlastnosti a metody. Vlastní typ Time 40
4.2. Implementace rezervační komponenty lze ve výsledku uložit jako 1 byte a pro potřeby komponenty je zcela vyhovující. • Třída Range Třída Range reprezentuje časový úsek. Třída obsahuje následující metody: – static Range Combine(Range range1, Range range2) - metoda vytvoří novou instanci třídy Range, jejíž rozsah bude sjednocením rozsahů předaných parametry. Sjednocení lze vypočítat pouze pro rozsahy, které se překrývají, v opačném případě bude výsledek hodnota null. – static Range Intersect(Range range1, Range range2) - metoda vytvoří novou instanci třídy Range, jejíž rozsah bude průnikem rozsahů předaných parametry. Průnik lze vypočítat pouze pro rozsahy, které se překrývají, v opačném případě bude výsledek hodnota null. • Třída TimeGroup Třída TimeGroup se skládá ze skupiny rozsahů otevírací doby, módu, ve kterém se aplikuje (bude vysvětleno v sekci výpočet výsledné otevírací doby) a seznamu dnů a měsíců, pro které se má použít. Třída obsahuje následující metody: – void Add(Range range) - metoda přidá rozsah do skupiny rozsahů. Pokud při přidání dojde k překrytí rozsahu s nějakým, který již obsahuje, dojde k jejich sloučení. Sloučení se provádí proto, aby skupina obsahovala co nejmenší množství rozsahů (menší velikost dat po serializaci, přehlednejší editace). – void Remove(Range range) - metoda funguje stejně jako metoda Add s rozdílem, že místo přidání rozsah odebere. – byte[] Serialize(TimeGroup timeGroup) - statická metoda, provádějící serializaci skupiny předané v parametru, vrací binární data. – TimeGroup Deserialize(byte[] data) - statická metoda, vytvářející instanci třídy TimeGroup. Její hodnoty jsou získané deserializací dat předaných parametrem. – TimeGroup Union(TimeGroup tg1, TimeGroup tg2) - statická metoda, vytvářející novou instanci třídy TimeGroup. Její rozsahy vypočítá jako sjednocení rozsahů skupin předaných v parametrech. Výsledná instance má vlasnosti Days, Months a Mode nastavené na výchozí hodnotu a je nutné je po provedení této metody upravit podle potřeby. – TimeGroup Diff(TimeGroup tg1, TimeGroup tg2) - statická metoda fungující stejně jako metoda Union, ale namísto operace sjednocení používá operaci rozdíl. 41
4. Realizace – TimeGroup Intersect(TimeGroup timeGroup1, TimeGroup timeGroup2) - metoda fungující stejně jako metoda Union, ale namísto operace sjednocení používá operaci průnik. – TimeGroup Invert(TimeGroup timeGroup) - statická metoda vytvoří novou instanci třídy TimeGroup a vypočítá její rozsahy jako opačné k rozsahům skupiny předané v parametru. Např. pokud předaná skupina obsahovala rozsah 10:00 - 12:00 bude výsledná skupina obsahovat rozsahy 00:00 - 10:00 a 12:00 - 23:59. Otevírací doba se skládá z několika instancí třídy TimeGroup (skupina rozsahů). Pro výpočet výsledné otevírací doby je nutné provést následující postup: 1. Vytvoří se nová instance třídy TimeGroup s prázdným rozsahem, která se stane mezivýsledkem výpočtu. 2. Postupně se projdou všechny skupiny rozsahů, které jsou platné pro požadovaný den a postupně se podle hodnoty vlastnosti Mode provede operace sjednocení nebo rozdíl. Výsledek této operace se stane novým mezivýsledkem výpočtu. 3. Mezivýsledek nyní obsahuje výslednou otevírací dobu. Systém umožňuje nastavit otevírací dobu pro: • celé sportovní centrum • konkrétní místnost • konkrétní aktivitu Nakonec je tedy nutné provést průnik otevírací doby celého sportovního centra, dané aktivity a dané místnosti. Během kontroly rychlosti zpracování akcí, týkajících se kalendáře bylo zjištěno, že výpočet otevírací doby je poměrně náročný a zabírá většinu času. Tento problém jsem vyřešil implementací cache paměti a cachováním výsledků výpočtu. Po této úpravě již nebyl s výkonem problém.
42
4.2. Implementace rezervační komponenty
Obrázek 4.7: Formát, ve kterém se ukládá otevírací doba
4.2.3.2
Rezervace multifunkčních místností
Multifunkční místnosti značně komplikují hledání volných termínů při zobrazování kalendáře obsazenosti. Jelikož zobrazování kalendáře obsazenosti je jedna z nejčastěji prováděných operací, bylo nutné navrhnout jeho sestavování co nejefektivněji. Nejprve bylo implementováno řešení následujícím způsobem: 1. Předpokládejme, že chceme sestavit kalendář obsazenosti pro aktivitu tenis 2. Načteme místnosti, které je možné použít pro aktivitu tenis 3. Ke každé místnosti načteme rezervace Počet provedených SQL dotazů u tohoto postupu nebude nekonstantní, ale bude záviset na počtu místností, které je možné pro aktivitu použít. Pro větší sportovní centra by tento postup nemusel být dostatečně efektivní. Rozhodl jsem se, hledat jiné řešení, které by ideálně umožňovalo konstantní počet dotazů. Výsledné řešení funguje tak, že při vytvoření nové rezervace dojde zároveň k vytvoření blokačních rezervací pro všechny aktivity, pro které lze místnost využít. Díky této úpravě lze načíst všechny rezervace pro danou aktivitu jediným dotazem. I přes to, že toto řešení není úplně ideální (způsobuje redundanci dat), bylo nakonec zvoleno a implementováno.
43
Kapitola
Testování V této kapitole popíši způsob provedení uživatelských testů rezervační komponenty, poté shrnu výsledek testů a nakonec navrhnu případné možnosti odstranění nedostatků. Testování bylo provedeno přímým pozorováním dvou testovacích subjektů. Pro potřeby testování byl systém naplněn testovacími daty a uživatelům byly připraveny uživatelské účty. Testování bylo zaměřeno na zákaznickou a zaměstnaneckou sekci, které jsou v rezervační komponentě klíčové.
5.1
Testovací scénáře
V této sekci popíši jednotlivé testovací scénáře, které uživatelé při testování plnili. 1. Zákazník - vytvoření rezervace - Zarezervujte si tenis na následující sobotu od 14:00 do 15:00. V případě, že není volno, zvolte co nejbližší čas. 2. Zákazník - zrušení rezervace - Zrušte všechny svoje budoucí rezervace na badminton. 3. Zaměstnanec - vytvoření rezervace - Vytvořte rezervaci tenisového kurtu na dnešní den od 18:00 do 19:00. Do poznámky uveďte, že se jedná o rezervaci pro osobu Jan Novák. 4. Zaměstnanec - potvrzení rezervace - Potvrďte všechny nepotvrzené rezervace. 5. Zaměstnanec - výluka - Zadejte do systému výluku na následující víkend. Jako důvod uveďte rekonstrukci.
45
5
5. Testování
5.2
Výsledek testování
Během testování podle testovacích scénářů číslo 2, 4 a 5 nebyly nalezeny žádné problémy. Testovací subjekty dokončily zadané úkoly bez problémů. Během testování podle testovacích scénářů číslo 1 a 3 bylo zjištěno několik nedostatků v rezervačním kalendáři. I přes tyto nedostatky zvládli testovací subjekty dokončit zadané úkoly. Nalezené nedostatky jsou následující: 1. Po vybrání termínu není možné vybrat jiný termín dokud uživatel nezavře formulář pro zadaní podrobností k rezervaci. Tento nedostatek se projevil když testovací subjekt vybral špatný časový úsek a snažil se výběr změnit bez zavření formuláře. 2. V rezervačním kalendáři není možné vybrat sousední buňky a tím určit délku rezervace. Testovací subjekt předpokládal, že klikáním na sousední buňky v rezervačním kalendáři dojde k prodloužení doby rezervace.
5.3
Možnosti řešení nedostatků
Všechny nalezené problémy nepředstavují zásadní problém, který by bránil v požívání systému. Systém lze plnohodnotně používat i v aktuálním stavu, ale je vhodné, pro zpříjemnění práce se systémem, tyto nedostatky odstranit.
46
Závěr Cílem mé bakalářské práce bylo navrhnout a implementovat rezervační komponentu pro informační systém sportovního centra. Myslím si, že práce splnila kladené požadavky a komponenta je připravena pro nasazení. Informační systém PLC ani rezervační komponenta zatím nepodporují jiné jazykové verze než je čeština, a proto by bylo vhodné v budoucnu systém rozšířit o možnost lokalizace do dalších jazyků. Při implementaci jsem se snažit komponentu navrhnout tak, aby jí v budoucnu bylo možné rozšiřovat o nové funkce. Hlavní důraz byl kladen na doménovou vrstvu, kterou v budoucnu mohou využívat některé další komponenty. Díky této práci jsem se naučil pracovat s novými technologiemi a prohloubil znalosti u těch, které jsem již dříve využil. Získané zkušenosti jistě využiji i v budoucích projektech.
47
Literatura [1] ASP.NET [online]. Microsoft, 2014 [cit. 2014-04-29]. Dostupné z: http: //www.asp.net [2] CSS Introduction [online]. W3Schools, 2014 [cit. 2014-04-29]. Dostupné z: http://www.w3schools.com/css/css_intro.asp [3] Entity Framework (EF) Documentation [online]. Microsoft, 2014 [cit. 201404-30]. Dostupné z: http://msdn.microsoft.com/en-us/data/ee712907 [4] HTML Introduction [online]. W3Schools, 2014 [cit. 2014-04-29]. Dostupné z: http://www.w3schools.com/html/html_intro.asp [5] JQuery [online]. The jQuery Foundation, 2014 [cit. 2014-04-29]. Dostupné z: http://jquery.com [6] Knockout [online]. knockoutjs.com
2014
[cit.
2014-04-29].
Dostupné
z:
http://
[7] Less documentation [online]. 2014 [cit. 2014-04-29]. Dostupné z: http:// lesscss.org [8] Microsoft .NET [online]. Microsoft, 2014 [cit. 2014-04-30]. Dostupné z: http://www.microsoft.com/net [9] Online rezervační systém JDEME NA TO [online]. 2014 [cit. 2014-04-29]. Dostupné z: http://rezervacnisystem.jdemenato.cz [10] Rezervační systém CLUBSPIRE [online]. 2014 [cit. 2014-04-29]. Dostupné z: http://www.clubspire.com/cs [11] Rezervační systém Rezervačník [online]. 2014 [cit. 2014-04-29]. Dostupné z: http://www.rezervacnik.cz 49
Literatura [12] TypeScript [online]. Microsoft, 2014 [cit. 2014-04-29]. Dostupné z: http: //www.typescriptlang.org [13] TypeScript Language Specification [online]. Microsoft, 2014 [cit. 2014-0429]. Dostupné z: http://go.microsoft.com/fwlink/?LinkId=267238
50
Příloha
Seznam použitých zkratek AJAX Asynchronous JavaScript and XML DLL Dynamic-link library DOM Document Object Model HTML HyperText Markup Language IoC Inversion of control JSON JavaScript Object Notation LINQ Language Integrated Query MVC Model-view-controller MVVM Model View ViewModel OOP Object-oriented programming ORM Object-relational mapping SQL Structured Query Language XHTML Extensible HyperText Markup Language
51
A
Příloha
Obsah přiloženého CD
readme.txt...................................stručný popis obsahu CD src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF manual.pdf ....................................... uživatelská přiručka install.pdf ....................................... instalační přiručka 53
B
