Masarykova univerzita Fakulta informatiky
Rezervační systém sportovišť
Bakalářská práce
Tomáš Hampl
Brno, podzim 2020 Masarykova univerzita Fakulta informatiky
Rezervační systém sportovišť
Bakalářská práce
Tomáš Hampl
Brno, podzim 2020 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení
Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Tomáš Hampl
Vedoucí práce: Mgr. Pavel Budík
i Poděkování
Na prvním místě bych rád poděkoval vedoucímu práce Mgr. Pavlu Budíkovi a celému týmu Webcentra, který mi pomohl s otestováním nového rezervačního systému. Dále bych rád poděkoval Ing. Vladimíře Kopuleté, která mě seznámila s původním rezervačním systémem.
ii Shrnutí
Cílem této práce je vytvoření nového rezervačního systému pro sportoviště spravovaná Fakultou sportovních studií Masarykovy Univerzity. Součástí práce je analýza původního rezervačního systému, na základě které vznikl návrh nového systému. Závěr práce je zaměřen na implementaci nového řešení. Nový systém byl integrován v univerzitním redakčním systému Umbraco. Zároveň se podařilo přenést veškerá potřebná data z původního rezervačního systému a úspěšně nový rezervační systém spustit.
iii Klíčová slova webová aplikace, rezervace, Umbraco, Angular, .NET
iv Obsah
1 Úvod 1
2 Redakční systém Webcentra 2 2.1 .NET Framework ...... 2 2.1.1 ASP.NET ...... 3 2.2 Content Management System ...... 3 2.3 Uživatelské sekce Umbraca ...... 4 2.4 Microsoft SQL Server ...... 5 2.4.1 Objektově relační mapování ...... 6 2.5 Klient–server model ...... 6 2.5.1 Vytvoření stránky na serveru ...... 7 2.5.2 Vytvoření stránky u klienta ...... 7 2.6 Životní cyklus formuláře ...... 8 2.6.1 Validace dat z formulářů ...... 10
3 Analýza původního rezervačního systému 12 3.1 Případy užití ...... 12 3.2 Uživatelé ...... 13 3.2.1 Uživatelské notifikace ...... 14 3.3 Rezervace ...... 15 3.3.1 Hromadné rezervace ...... 15 3.4 Roční cyklus ...... 15 3.5 Administrátorská sekce ...... 16 3.5.1 Financování ...... 16 3.5.2 Statistika ...... 17 3.6 Analýza uložených dat ...... 17
4 Návrh nového rezervačního systému 19 4.1 Typy rezervací ...... 20 4.2 Uživatelské skupiny ...... 20 4.3 Spravování rezervačního systému ...... 21 4.3.1 Sportoviště a areály ...... 21 4.3.2 Uživatelé a skupiny ...... 21 4.3.3 Typy rezervací ...... 22 4.3.4 Spravování rezervací ...... 22
v 4.4 Databáze ...... 22 4.5 Uživatelské rozhraní ...... 24
5 Implementace systému 26 5.1 Webová stránka ...... 26 5.2 Rezervační kalendář ...... 26 5.3 Export rezervací ...... 30 5.3.1 Export pro správce ...... 31 5.3.2 Export pro ekonomické oddělení ...... 32 5.4 Import rozvrhů ...... 32 5.5 Import dat ze starého systému ...... 35
6 Závěr 38
Bibliografie 39
A Elektronické přílohy 41
vi Seznam obrázků
2.1 Ukázka sekce Obsah 4 2.2 Ukázka sekce Webdata 5 2.3 Životní cyklus komponenty 9 3.1 Případ užití rezervačního systému 13 3.2 Schéma části databáze 18 4.1 Upravené případy užití na základě analýzy 19 4.2 Diagram databáze pro nový rezervační systém 23 4.3 Shrnutí rezervace v původním systému 25 5.1 Ukázka kalendáře vytvořená díky fullcalendar 27 5.2 Ukázka kalendáře vytvořená díky angular-calendar 28 5.3 Ukázka exportní třídy 31 5.4 Ukázka rozhraní pro export rezervací 31 5.5 Ukázka rozvrhu ve formátu XML 34 5.6 Ukázka poznámky k rozvrhu 34
vii 1 Úvod
Na Fakultě sportovních studií (FSpS) Masarykovy univerzity mají studenti možnost v rámci výuky navštěvovat nejrůznější sportoviště jako například posilovnu, tělocvičnu nebo tenisové kurty. Tato sportoviště však nejsou výukou plně vytížena, proto jsou ve zbývajícím čase k dispozici pro veřejnost. Pro možnost zarezervovat si volné sportoviště v současné době slouží rezervační formulář, který je k dispozici pro registrované uživatele na stránkách fakulty. Rezervační formulář je součástí rezervačního systému, ve kterém mají administrátoři mimo jiné možnost upravovat nastavení systému a pracovat s daty. Webové stránky FSpS přecházejí pod správu Ústavu výpočetní techniky (ÚVT) Masarykovy univerzity v rámci poskytovaných služeb Webcentra. Proto i tento rezervační systém je součástí tvorby nových webů. Rezervační systém, který byl vytvořen přímo pro potřeby FSpS, pomalu zastarává a je tedy vhodné systém upravit a přizpůsobit novým podmínkám a požadavkům. Z toho důvodu vznikne nový rezervační systém, který bude založený na nových technologiích a zaměří se na opravu nedostatků původního systému. Cílem této bakalářské práce je vytvoření nového rezervačního systému, který převezme původní funkcionalitu a tu dále rozšíří. Převážně se zaměříme na vylepšení administrační sekce, abychom zlepšili a ulehčili každodenní rutinní práci správce. V první kapitole jsem se zaměřil na popis redakčního systému Webcentra, jeho hlavní úkol a jednotlivé funkcionality. V druhé kapitole jsem se zaměřil na analýzu starého systému a zachytil jsem jeho hlavní požadavky. Při analýze jsem se zaměřil na možnost jeho vylepšení a odstranění nedostatků. Výsledkem analýzy je i vytyčení hlavních bodů, které bude nový systém obsahovat. V následující kapitole jsem se zaměřil na samotný návrh nového rezervačního systému. Při návrhu používám znalosti nabyté při analýze starého systému a navrhuji vhodné řešení problémů a nedostatků starého systému. V poslední kapitole popisuji implementaci systému.
1 2 Redakční systém Webcentra
Tým Webcentra spravuje více než 300 webových stránek a pro tyto účely se v rámci Webcentra využívá redakční systém (Content Management System). Jedná se o systém pro správu obsahu, v našem případě jde o správu jednotlivých webových stránek. Podobné systémy, které se v těchto případech používají, jsou například WordPress, Joomla a nebo Drupal. Redakční systém Webcentra však v tomto případě běží na open-source platformě Umbraco, která je založena na .NET Frameworku. Proto se v této kapitole blíže podívám na již zmíněnou platformu Umbraco a na technologie, které nabízí pro vývoj webových stránek.
2.1 .NET Framework
Celý redakční systém běží na .NET Frameworku 4.7.2. .NET Framework je běhové prostředí pro Windows, které poskytuje běžícím aplikacím celou škálu služeb (například správa paměti, rozšiřující knihovny nebo základní typový systém). Skládá se ze dvou základních částí:
∙ Common Language Runtime (CLR) – jedná se o běhový engine, který má na starost běžící aplikace
∙ Class Library (CL) – poskytuje knihovnu testovaného a znovupoužitelného kódu, který vývojáři mohou využít při vytváření vlastních aplikací
Aplikace může být napsána v C#, F# nebo Visual Basicu. Tyto jazyky pak překladač převede na Common Intermediate Language (CIL). Přeložený kód je uložen v assemblies. Při běhu aplikace jsou pomocí just-in-time překladače (tj. překladu za běhu) assemblies převedeny do strojového kódu, který může běžet na dané architektuře počítače. Pro vývoj redakčního systému je použit C#, který je objektově orientovaný a staticky typovaný programovací jazyk [1].
2 2. Redakční systém Webcentra
2.1.1 ASP.NET Součástí frameworku je i ASP.NET, který je zaměřený přímo na tvorbu webových aplikací. Je vytvořen pro práci s Hyper Text Transfer Protokolem (HTTP), který je založený na principu požadavek-odpověď. Poskytuje tři frameworky pro tvorbu webových stránek a aplikací (Web Forms, ASP.NET MVC, ASP.NET Web Pages), které sdílí základní funkcionalitu jako jsou model zabezpečení přihlášení, správa požadavků, zpracování relací atd. Použití jednoho z nich nevylučuje možnost použití jiného. To znamená, že jednotlivé komponenty aplikace mohou využívat různé frameworky [2]. Dále také nabízí jednoduchý způsob pro vytváření webových aplikačních rozhraní (API) díky frameworku ASP.NET Web API, který podporuje širokou škálu klientů, jeho součástí jsou i prohlížeče a mobilní zařízení. Součástí ASP.NET je i Razor View Engine. View engine slouží k tomu, aby transformoval view uložené v paměti do požadované formy. V případě Razoru jde o převod CSHTML souboru na stránku v HTML. Razor poskytuje zjednodušenou formu syntaxe, která obsahuje jak prvky značkovacího jazyka HTML, tak i programovacího jazyka C#. Využívá se ke tvorbě jednoduchých i složitějších dynamických stránek. Proces vytváření stránky v HTML probíhá na straně serveru a uživatel dostane již vytvořenou stránku [3].
2.2 Content Management System
Umbraco poskytuje administrátorům webových stránek stavebnici v jednotném vizuálním stylu univerzity. K úpravě a tvorbě nových stránek se používají komponenty, které je možné uspořádávat do mřížky. Ve většině případů se jedná o WYSIWYG editory („What You See Is What You Get“). Tyto editory zobrazují uživateli obsah tak, jak bude vypadat na webu. Proto webové stránky mohou upravovat i osoby, které nemají znalost programování. Naopak vývojářům nabízí prostředky pro jednoduché vytváření vlastních datových typů nebo automatického výpisu pro dané webové stránky. Díky tomu, že se jedná o open-source platformu, je možné Umbraco upravit podle vlastních potřeb.
3 2. Redakční systém Webcentra 2.3 Uživatelské sekce Umbraca
Funkcionalita redakčního systému je pro uživatele rozdělena do různých sekcí. Nejdůležitější z nich jsou popsány v této části. Sekce Obsah (viz obrázek 2.1) slouží k samotné tvorbě obsahu stránek a pro obecné nastavení webu (například zobrazení záhlaví nebo nastavení jazykových verzí webu). Každá stránka se skládá z uzlů, které jsou uspořádány do stromové struktury. Uzly se skládají z dokumentového typu a šablony. Dokumentový typ definuje, co všechno bude možné danému uzlu nastavit. Šablona definuje pomocí Razoru výsledný vzhled uzlu jako webové stránky. Pokud není šablona vybrána, tak daný uzel slouží pouze k úpravě nastavení buď celého webu nebo jen konkrétní funkcionality. Pokud je šablona vybrána, tak je ve většině případů používána především pro převod komponent do finální podoby stránky. Na druhé straně je možné vytvořit vlastní vzhled stránky právě díky šabloně.
Obrázek 2.1: Ukázka sekce Obsah
V sekci Webdata uživatelé mohou spravovat dodatečná data k webu (viz obrázek 2.2). Zpravidla se jedná o přehled registrací do newsletteru nebo vytváření formulářů a přehled jejich odpovědí. Hlavním využitím je však administrace modulů, které byly vytvořeny na míru pro daný web. Z programátorského hlediska je velmi
4 2. Redakční systém Webcentra
jednoduché vytvořit stránkovaný výpis dat s proklikem na detail záznamu a možnost jeho editace.
Obrázek 2.2: Ukázka sekce Webdata
2.4 Microsoft SQL Server
Redakční systém Umbraco ukládá data do relační databáze Microsoft SQL Server, proto i ostatní data potřebná k provozu webových stránek využívají stejný databázový systém. V relační databázi jsou data logicky uspořádána do relací. Jednotlivé relace reprezentují tabulky v databázi a skládají se z atributů a množiny uspořádaných n-tic. Atributy definují jméno a typ daného sloupce tabulky a uspořádané n-tice reprezentují data v databázi, která odpovídají řádku tabulky. Každá relace má alespoň jeden seznam atributů, které jednoznačně určují její uspořádanou n-tici, tzv. kandidátní klíče. Pogramátor pak vybere z těchto kandidátních klíčů jeden, který se stane primárním klíčem. Umbraco využívá k identifikaci jednotlivých prvků číselné hodnoty. K přístupu a modifikaci různých dat slouží transakce. Před začátkem a po vykonání transakce je databáze v konzistentním stavu. Po provedení transakce jsou změny v databázi trvalé, i když nastanou systémové chyby [4]. Databáze vytvořená v Microsoft SQL Serveru ukládá data do souborů v souborovém systému. Tyto soubory lze rozdělit na datové
5 2. Redakční systém Webcentra
soubory a log soubory. Datové soubory obsahují tabulky, indexy, uložené procedury a šablony. Log soubory uchovávají data potřebná k obnovení všech transakcí v databázi [5]. Data, se kterými pracuje redakční systém, by se dala rozdělit do tří typů. Prvním typem jsou data, která náleží přímo redakčnímu systému, takže o jejich správu se stará Umbraco. Zpravidla se jedná o nastavení a obsah jednotlivých stránek. Druhým typem jsou data přebíraná z jiných systémů Masarykovy univerzity. Tato data jsou importována pravidelně ve zjednodušené formě, aby tak urychlila zpracovávání požadavků. Posledním typem jsou data, která jsou specifická pro jednotlivé webové stránky a o jejich správu sestará tým Webcentra. Tato data vznikají speciálně na míru pro daný web.
2.4.1 Objektově relační mapování Nad relačními daty může být ještě postavený systém, který z objektů v programovacím jazyce vytvoří relační data a naopak. Tento systém má na starosti vkládání, mazání a aktualizování dat v databázi [4]. Pro tyto účely využíváme rozšiřující balíček pro .NET, který se jmenuje PetaPoco1. Jedná se o malý, rychlý a jednoduše použitelný balíček. Při práci s tímto rozšířením jsme vytvořili množství funkcí, které usnadňují práci s databází. Toto rozšíření také umožňuje automatické generování tříd v programovacím jazyce.
2.5 Klient–server model
Webové aplikace jsou typickým příkladem klient-server modelu, který je založen na komunikaci mezi oběma stranami pomocí sítě. Do komunikace jsou zapojeny dva procesy, kdy jeden běží na straně serveru a druhý na straně klienta. Proces na straně klienta zasílá požadavky na stranu serveru, která na ně odpovídá. Server by měl být schopen vyhovět většímu počtu požadavků od klientů zároveň [6]. Podle toho, na jaké straně běží logika aplikace, se rozlišují dva základní typy klientů: thin a thick. Pro thin klienta je typické, že většina logiky se provádí na straně serveru a na klienta (uživatele aplikace) se posílá vzhled stránky. Naopak u thick klienta server
1. https://github.com/CollaboratingPlatypus/PetaPoco
6 2. Redakční systém Webcentra pouze posílá data a aplikaci, pomocí které se na klientovi daná data zobrazí. V obou případech lze vytvořit statické i dynamické stránky, ale hlavním rozdílem těchto stránek je zatížení serveru. V praxi dochází ke kombinaci těchto dvou přístupů, kdy část logiky se provede na straně serveru a část na straně klienta.
2.5.1 Vytvoření stránky na serveru Na straně serveru se vygeneruje stránka, která je zaslána klientovi. Při generování stránky se využijí zdroje serveru (nejen jeho výpočetní síla, ale i například data uložená v databázi). Důvodem generování stránky pro každého klienta je to, že její podoba může být různá pro každého klienta. Například se její podoba může změnit přihlášením uživatele nebo změnou textu v redakčním systému.
2.5.2 Vytvoření stránky u klienta V případě tvorby stránky u klienta se stáhne kód, který běží v jeho prohlížeči. Ve většině případů se používá JavaScript, ale existují i jiné varianty jako je například WebAssembly nebo Blazor. JavaScript je interpretovaný, objektově orientovaný skriptovací jazyk převážně určený pro tvorbu webových stránek. Běží na straně uživatele v prohlížeči, takže jeho chování může být upraveno na základě událostí od uživatele. Používá se převážně k úpravě chování webové stránky [7]. Na rozdíl od tvoření stránky na serveru je závislý na výkonu zařízení na straně uživatele. Z toho důvodu je tato část složitější na optimalizaci. Pro účely tvoření webů využíváme Framework Angular2. Jedná se o JavaScriptový framework určený pro jednostránkové aplikace [8], které jsou založeny na principu, že načtou na začátku jeden web dokument. Tento dokument pak upravují pomocí JavaScript API. Angular využívá pro tvorbu webových stránek jazyky HTML a TypeScript. TypeScript je open-source programovací jazyk založený na JavaScriptu, ale nabízí i statické typování a výsledný kód je překládán do JavaScriptu [9]. Základním stavebním kamenem aplikace v Angularu jsou komponenty, které jsou organizovány do
2. https://angular.io/ 7 2. Redakční systém Webcentra
NgModules (dále jen moduly). Aplikace je pak tvořena množinou těchto modulů. Moduly slouží k rozdělení kódu do funkčních celků, což ulehčuje vývoj složitějších aplikací a podněcuje znuvupoužitelnost komponent. Modul definuje překladový kontext pro jeho množinu komponent. Je možné využít funkcionalitu z jiných modulů a také umožnit export funkcionality z daného modulu, který pak mohou využívat jiné moduly. Aplikace vždy obsahuje kořenový modul, který se stará mimo jiné i o spuštění aplikace. Využívám také možnosti načítat moduly líně, abychom snížili množství kódu, který je potřebný na startu aplikace [10]. Každá aplikace má alespoň jednu komponentu, která se nazývá kořenovou. Tato komponenta se stará o propojení hierarchie komponent s objektovým modelem dokumentu stránky (DOM). DOM reprezentuje webovou stránku jako uzly a objekty, se kterými mohou programovací jazyky manipulovat a tím měnit vzhled stránky [11]. Každá komponenta se skládá ze třídy, která obsahuje aplikační data a logiku, a šablony, která se stará o její zobrazení. Šablony využívají HTML doplněné o speciální značky, které upravují HTML elementy ještě před jejich zobrazením. Komponenty využívají služby poskytující funkcionalitu, která nemusí být přímo závislá na dané komponentě. Díky vkládání závislostí jsou tyto služby vloženy do komponenty, což vytváří znovupoužitelný kód. Angular view pak tvoří komponenta (napsaná v TypeScript) a šablona (napsaná v HTML) a jejich vztah je popsán na obrázku 2.3.
2.6 Životní cyklus formuláře
Formuláře v Umbracu se vkládají na stránku stejně jako ostatní webové komponenty v rámci editoru. V případě formulářů se jedná o speciální komponentu, která se postará o vložení angular aplikace na stránku. V okamžiku, kdy uživatel načítá stránku, server vytvoří HTML strukturu stránky. V této struktuře je záhlaví a zápatí webu a v těle stránky jsou vloženy komponenty, které jsou na stránce, jejichž součástí je i vložení angularu. Do hlavičky stránky se ještě přidá odkaz
8 2. Redakční systém Webcentra
Obrázek 2.3: Životní cyklus komponenty (Převzato z https:// angular.io/guide/architecture)
na skripty potřebné k běhu Angular aplikace. Následně se na straně uživatele spustí Angular, který se postará o vykreslení konkrétních komponent. Následně Angular komunikuje se serverem přes různá API, aby předal data z formulářů nebo aby získal potřebná data k zobrazení. Každá odpověď serveru má vlastní stavový kód, který je blíže popsaný v RFC 7231 [12]. Stavový kód je složen ze tří číslic a určuje význam takové odpovědi. Blíže se podíváme na rozdělení jednotivých kódů, které využijeme v našem rezervačním systému.
∙ 2xx (Successful) – Požadavek byl na serveru zpracován a proběhl úspěšně.
∙ 4xx (Client Error) – Požadavek má špatnou syntaxi a nebo mu nebylo možné vyhovět.
– 400 (Bad Request) – Server nemůže nebo nechce vyhovět požadavku, protože nastala chyba na straně klienta. V našem případě se jedná o nevhodné objekty, které se posílají na server.
9 2. Redakční systém Webcentra
– 403 (Forbidden) – Server pochopil požadavek, ale odmítl ho provést, protože uživatel nemá oprávnění. – 404 (Not Found) – Server nenašel požadovaná data nebo nechce sdělit jejich existenci. – 409 (Conflict) – Server nemůže vyhovět požadavku, protože nastal konflikt se stávajícím stavem. Například se dá využít při registrace uživatele, pokud má mít unikátní e-mail. ∙ 5xx (Server Error) – Nastala chyba na serveru při zpracovávání požadavku.
2.6.1 Validace dat z formulářů Ke tvorbě formulářů se využívá Angular, který data posílá v podobě JSONu na server, kde se dále zpracovávají. Samotná validace dat probíhá na straně uživatele díky Angularu, ale i na straně serveru, aby se ověřila jejich platnost, jestli s nimi někdo nemanipuloval nebo neposlal podvržená data. Proto je důležitá validace na straně serveru. Validace na straně klienta zlepšuje především interakci uživatelů s formulářem. Pro validaci dat na straně serveru využíváme .NET knihovnu Fluent Validation3, která slouží ke tvorbě silně typovaných pravidel pro objekty. V případě, že objekt nevyhovuje definovaným pravidlům, vygeneruje knihovna chybové hlášky, které jsou lokalizované a přesně řeknou, kde je chyba. Tyto chybové hlášky se pak pošlou zpátky formuláři, který je zobrazí. K samotné validaci formulářů v Angularu slouží komponenta FormControl4, která obsahuje jednotlivé hodnoty formuláře a validátory, které k daným hodnotám patří. Proto je možné jednoduše u jednotlivých položek zjistit zda jsou vyplněny správně nebo ne a podle toho přizpůsobit formulář, který například zobrazí text nebo podbarví políčko červeně. Případně lze upravit chování i podle toho, který validátor položky je špatně, lze změnit znění textu, který informuje uživatele, co přesně vyplnil špatně. Například při
3. https://fluentvalidation.net/ 4. https://angular.io/api/forms/FormControl
10 2. Redakční systém Webcentra
registraci uživatel vyplňuje e-mail a může být upozorněn, že nezadal platnou e-mailovou adresu, nebo že zadal e-mailovou adresu, která již existuje v systému. Nevýhodou dvojí validace je, že v případě změny ve validaci je potřeba upravit ji jak na straně serveru, tak i v Angularu.
11 3 Analýza původního rezervačního systému
Rezervační systém využívá univerzita k rezervaci sportovišť pro potřeby studia podle aktuálních rozvrhů. Zároveň slouží veřejnosti k možnosti zarezervovat si jednotlivá volná sportoviště. Pro každé sportoviště nabízí rezervační formulář, díky kterému je možné vytvořit rezervace na konkrétní termín. Toto je umožněno pouze přihlášeným uživatelům. Proto se tento systém stará také o správu uživatelů a uživatelům nabízí možnost registrace, přihlášení, odhlášení a upravení jejich osobních údajů. Pro správce systému nabízí rozšířenou funkcionalitu. Umožňuje správci importovat rozvrhy, aby nedocházelo ke konfliktům rozvrhu a rezervací od uživatelů. Dále nabízí možnost vytvoření seznamu uživatelů a částky za dané období, kterou mají zaplatit. Tento seznam se vytváří vždy za uplynulý měsíc a posílá se na ekonomické oddělení, kde vytvoří pro uživatele faktury k zaplacení. Další funkcionalitou je vytvoření statistiky, která ukazuje obsazenost jednotlivých sportovišť. Tato statistika slouží převážně pro interní potřeby. Současný rezervační systém funguje jako webová aplikace, která je naprogramovaná v jazyce PHP a pro formuláře se využívá JavaScript. Tento systém byl vytvořen na míru pro FSpS v roce 2012 a od té doby neproběhly větší úpravy systému. Proto tento systém zastarává a nepodporuje nové technologie. A tedy se nepřizpůsobuje novým potřebám uživatelů a správců systému.
3.1 Případy užití
K popisu toho, jak se systém využívá, je určen Unified Modeling Language (UML [13]). Na obrázku 3.1 je zobrazen základní diagram případu užití současného rezervačního systému. Případy užití specifické pro rezervační systém jsou podrobněji popsány v následujících sekcích. Jednotliví aktéři diagramu jsou popsáni v sekci 3.2. Diagram je důležitý, protože se podle něj řídím při návrhu nového systému.
12 3. Analýza původního rezervačního systému
Obrázek 3.1: Případ užití rezervačního systému
3.2 Uživatelé
Uživatelé mohou být rozděleni do skupin. Skupiny slouží k tomu, aby určovaly cenu pro jednotlivá sportoviště. Uživatel pak při vytváření rezervace vybírá ze skupin, do kterých patří, a od toho se odvíjí cena za rezervaci. Každý uživatel se může nacházet v libovolném počtu skupin, které mu přiřadí administrátor. Pokud však uživatel není v žádné skupině, tak nemůže vytvořit rezervaci. Typicky se nachází uživatel pouze v jedné skupině. Uživatelé jsou rozděleni pouze do dvou skupin a to „běžný uživatel“ a „výuka a akce FSpS“. Běžný uživatel platí za využití sportoviště a výuka s akcemi je zadarmo. Speciální skupinou běžných
13 3. Analýza původního rezervačního systému
uživatelů jsou smluvní partneři. Jsou to speciální uživatelé, kteří mají předem nasmlouvané ceny za sportoviště. Administrátoři spravují jejich účty a starají se o vytváření rezervací na základě dohodnutých smluv. Dále každý uživatel může být administrátorem. Tuto funkci může přidělit jiný administrátor. Možnosti administrátora jsou mnohem rozsáhlejší než běžného uživatele. Takový uživatel dostane přístup do administrátorské sekce (viz sekce 3.5) a mění se pro něj pravidla pro vytváření rezervací, jak je popsáno v sekci 3.3. Takové rozdělení uživatelů je velice jednoduché a nepotřebuje složitého nastavování, ale na druhou stranu je velice nepraktické. Hlavní problém nastává při fakturaci a statistice. Například neplánovaná porucha se musí řešit tím, že se vytvoří rezervace, která se potom musí ručně odebírat ze seznamu pro fakturaci a také ovlivňuje statistiku. Proto jsem přesvědčen, že prvotní nastavení by mohlo být trochu složitější, ale zase by bylo flexibilnější a mohlo by i administrátorům poskytnout lepší flexibilitu a v budoucnu jim ušetřit práci.
3.2.1 Uživatelské notifikace Uživatelé jsou notifikováni e-mailem v těchto případech: ∙ Při registraci – Uživateli je zaslán e-mail se všemi údaji, které vyplnil, včetně hesla. E-mail obsahuje i validační kód a odkaz na ověření e-mailu, který má podobu validačního kódu. Po ověření e-mailu se stává účet platným. ∙ Při změně údajů – Uživatel obdrží e-mail s aktualizovanou verzí údajů. Je podobný jako při registraci, jen heslo, validační kód a odkaz na ověření už nejsou vyplněné. ∙ Při vytvoření rezervace – Uživatel dostane e-mail v případě, že sám vytvořil rezervaci, nebo za něj vytvořil rezervaci administrátor. ∙ Při zrušení rezervace – Obdobně jako při vytvoření rezervace. Množství notifikací je dostatečné, ale není možné si nastavit, které notifikace chce uživatel dostávat. Navíc při těchto notifikacích není možné poznat, jestli změnu provedl uživatel sám, nebo jestli změnu provedl správce systému za uživatele. Všechny tyto notifikace také chodí správci systému, což způsobuje zahlcení jeho e-mailové
14 3. Analýza původního rezervačního systému
schránky. Proto by bylo dobré tyto změny v systému zaznamenávat jiným způsobem.
3.3 Rezervace
K rezervacím slouží rezervační formulář, který je stejný pro běžného uživatele i pro administrátora. Rezervaci lze vytvořit pro zvolené sportoviště na zvolený časový úsek zaokrouhlený na půlhodiny. Administrátor může na rozdíl od běžného uživatele vytvářet zpětné rezervace a má k dispozici možnost rušit rezervace, může provádět i různé drobné změny například přesunutí rezervace na jiný termín. Dále administrátor může vytvořit rezervaci za někoho jiného. V praxi to funguje tak, že si před vytvořením rezervace zvolí, za kterého registrovaného uživatele chce rezervaci vytvořit. Tato funkce se převážně týká smluvních partnerů.
3.3.1 Hromadné rezervace Pro vytvoření více rezervací najednou složí hromadná rezervace, která je dostupná pouze správcům. Od rezervace jednoho termínu se liší tím, že se dá vybrat rozmezí od do a v něm vybrat ve které dny v týdnu se má rezervace vytvořit. Tato funkcionalita je velice užitečná, proto by bylo dobré ji zachovat. Hromadnou rezervaci bylo možné zrušit buď celou a nebo jednotlivé rezervace. Ovšem pokud se jedná o déle se opakující činnost a je potřeba zrušit pouze její část, tak se musí úkon dělat ručně. Proto by bylo dobré přidat možnost zrušit hromadnou rezervaci pouze v určitém rozmezí.
3.4 Roční cyklus
Každé sportoviště má vlastní tzv. „hraniční datum“. Jedná se o datum, po kterém běžný uživatel nemůže vytvářet rezervace. Jednou z jeho hlavních funkcí je omezit možnost rezervace uživatelů před vytvořením rozvrhů fakulty, případně po dobu plánované dlouhodobé nedostupnosti sportoviště. Typicky se tedy nastavuje na začátek semestru a po vytvoření a importu rozvrhů je toto datum manuálně
15 3. Analýza původního rezervačního systému
změněno administrátorem. Tím pádem je to velice důležitá součást rezervačního systému. Toto datum však není nijak zobrazeno v rezervační formuláři a to je pro běžné uživatele matoucí v případě, že si chtějí vytvořit rezervaci po tomto datu. Při uložení se jim pouze zobrazí chybová hláška, že překročili hraniční datum, ale už neví, co tento termín znamená, kdy je toto datum, do kterého mohou vytvářet rezervace. V této oblasti je nutné provést úpravu.
3.5 Administrátorská sekce
Tato sekce je přístupná pouze administrátorům a od rezervačního systému pro běžného uživatele není nijak oddělená, pouze v horním menu je více položek. Slouží k různým nastavením a správě celého systému. Do této sekce má přístup pouze omezený počet osob, které se pravidelně starají o běh celého systému. Protože některé aktivity administrátorů jsou rutinní, je vhodné, aby jejich používání bylo jednoduché a časově nenáročné.
3.5.1 Financování
Proběhnuté rezervace se platí zpětně vždy na konci měsíce. Samotný systém nespravuje placení za jednotlivé rezervace ani nezprostředkovává platby. Pronájem sportovišť se vždy fakturuje za celý měsíc, faktury vyhotovuje ekonomické oddělení, které nemá přístup do systému. Za tímto účelem je k dispozici možnost vytvořit si seznam za zvolené období. Seznam obsahuje vždy všechny rezervace za dané období, které jsou uspořádány podle uživatele. Po rezervacích daného uživatele se nachází řádek se shrnutím a celkovou částkou k zaplacení. Nevýhodou je, že v tomto seznamu jsou zahrnuti všichni uživatelé včetně rozvrhů a smluvních partnerů. Proto se ještě musí ručně opravovat a všechny takové záznamy odebrat. Teprve potom se tento seznam předá na ekonomické oddělení, které jednotlivým uživatelům vytvoří faktury k zaplacení.
16 3. Analýza původního rezervačního systému
3.5.2 Statistika Pro libovolné období, které si zvolí správce, lze vytvořit z dat uložených v systému seznam o obsazenosti jednotlivých sportovišť. V něm se nachází procentuální obsazenost pro jednotlivé uživatelské skupiny a pro všechny skupiny dohromady. Obsazenost je rozdělena na pracovní dny a víkendy. Slouží k interním potřebám fakulty, aby měla přehled o celkové obsazenosti sportovišť. Dále mohou být seznamy využity pro potřeby rektorátu, který s těmito přehledy rovněž pracuje.
3.6 Analýza uložených dat
Jedním z požadavků na nový systém je také zachovat data uložená v původním. Jedná se o data o uživatelích, jejich účtech a aktuálních slevách, bylo by nepraktické, aby si uživatelé vytvářeli nové účty, viz schéma 3.2. Dále je potřeba přenést rezervace, které mají proběhnout až po přechodu na nový systém. Ostatní data uložená v systému se přenášet nebudou, protože se jedná pouze o jednotky záznamů a bylo by náročnější tato data přenášet automaticky. Týká se to sportovišť a uživatelských skupin. Data jsou uložena v relační databázi MySQL. Jedná se o softwarové řešení Structured Query Language(SQL).
17 3. Analýza původního rezervačního systému
Obrázek 3.2: Schéma části databáze
18 4 Návrh nového rezervačního systému
Cílem této kapitoly je díky znalostem požadavků na systém, představených v předchozí kapitole, navrhnout nové řešení, které bude integrováno v redakčním systému Umbraco. Na obrázku 4.1 jde vidět, jak se případy užití změnily na základě analýzy. Nově přidané případy jsou zvýrazněny zeleně.
Obrázek 4.1: Upravené případy užití na základě analýzy
19 4. Návrh nového rezervačního systému 4.1 Typy rezervací
Pro lepší využití skupin je nově zaveden typ rezervace, který bude ovlivňovat cenu dané rezervace. Typ rezervace částečně nahrazuje skupiny z původního systému. To znamená, že ceník i slevy jsou vázané na něj a uživatelé vybírají při vytváření rezervace typ rezervace. Každá skupina má povolené typy rezervací a může pro ně mít vlastní slevy.
4.2 Uživatelské skupiny
Na rozdíl od původního systému je v novém systému více skupin uživatelů. Bylo to možné i v původním systému, ale nevyužívala se možnost rozdělení uživatelů do více skupin. Dobrým příkladem využití nových skupiny je skupina „handicapovaní“, kteří mají na všechna sportoviště slevu 20 %. Jelikož se musí vytvořit pro každé sportoviště speciální sleva, tak by se u každého handicapovaného uživatele musela pro každé sportoviště vytvořit sleva. Díky tomu, že jsou slevy už vytvořené pro skupinu, stačí pouze uživatele přiřadit do této skupiny. Uživatelé budou lépe rozděleni do různých skupin a správa slev tak bude také jednodušší. Uživatelé se také mohou nacházet ve skupinách, jejichž členové mohou vytvářet rezervace zdarma, ale takové rezervace budou muset být předem schválené správcem. Správci to zjednoduší práci, protože nemusí vytvářet danou rezervaci, ale podívá se na ni a pouze schválí nebo zruší. Vhodné je toto využití i pro skupinu „učitelé“, kteří na konci roku potřebují vytvářet rezervace pro zkoušky, ale zároveň mohou chodit na sportoviště ve svém volném čase. Takovému uživateli stačí pouze jeden účet, který může využít jak k pracovním, tak i soukromým účelům. Skupina může být uživateli přiřazena i automaticky. K tomu dochází na základě propojení účtu s jeho univerzitním číslem osoby (učo) na Masarykově univerzitě pomocí jednotného přihlášení. Výhodou takových skupin je, že uživatel může čerpat slevy, na které má nárok, protože je například zaměstnancem FSpS.
20 4. Návrh nového rezervačního systému 4.3 Spravování rezervačního systému
Uživatelské prostředí pro správu systému je možné rozdělit do Umbraca a nebo na web. Na webu jsou pouze ty části, které není jednoduché implementovat v Umbracu (více v podsekci 4.3.4). Přesto je důležité, aby se většina administrace prováděla v Umrabcu, aby byla pro administrátory jednodušší a měli ji na jednom místě. V Umbracu je možnost rozdělit správu buď do Obsahu, nebo do Webdat. V Obsahu jsou zpravidla takové části, které je potřeba zobrazit i na webu. Naopak ve Webdatech jsou dodatečná data k webu. Samotné nastavení rezervačního sytému se nachází v Umbracu v Obsahu. Jedná se o globální nastavení celého systému (například nastavit, jestli je systém otevřen pro veřejnost). Nastavení však neslouží k zobrazení na webu, ale přesto se nachází v Obsahu, protože slouží i k nastavení e-mailů, které rezervační systém posílá uživatelům i správcům. Texty jednotlivých e-mailů je proto možné upravovat podobně jako stránky a je možné vidět vzhled e-mailu již při editaci. Dalším důvodem, proč se nachází v Obsahu, je, že je potřeba nastavit přesměrování uživatele po určitých akcích nebo vytvořit odkazy v hlavičce webu. Pro tyto účely je jednoduché v Obsahu vytvořit pár políček, která administrátor může upravovat.
4.3.1 Sportoviště a areály
Na webu je důležité, aby se zobrazil seznam sportovišť i areálů. Proto je nutné, aby sportoviště i areály byly v Umbracu v Obsahu. Výpis jednotlivých sportovišť i areálů je statická stránka, která nepotřebuje vstupy od uživatele. Proto se většina jejího obsahu bude generovat na straně serveru.
4.3.2 Uživatelé a skupiny
Jak jsem psal výše, pro správu dodatečných dat k webu slouží v Umbracu sekce Webdata. Ve Webdatech je velmi jednoduché vytvořit stránkovaný výpis uživatelů i skupin a vytvořit filtr přímo na míru daným datům. Proto je možné uživatel filtrovat podle jejich skupin, ale i podle e-mailu nebo jména.
21 4. Návrh nového rezervačního systému
4.3.3 Typy rezervací
Tato část rezervačního systému se může nacházet jak v sekci Obsahu, tak i ve Webdatech. Důvod, proč se nachází v sekci Obsah, je ten, že je to jednodušší na vytvoření a také je jednodušší vytvořit z dat v sekci Obsah políčko pro výběr. Toto políčko je pak využito při úpravě sportovišť, kde je potřeba vytvořit ceník vázaný právě na konkrétní typ rezervace.
4.3.4 Spravování rezervací
Jedná se o jedinou část administrace, u které je vhodnější, když nebude v Umbracu, ale na webu. Jeden z důvodů je, že v Umbracu nemá podporu pro kalendář, který by zobrazoval rezervace, a ve kterém by bylo jednoduché tyto rezervace mazat a vytvářet nové. Jednou z možností by bylo vypisovat rezervace v listu pod sebou chronologicky uspořádané, ale tento způsob není velmi přehledný pro každodenní práci. Proto bude snazší rozšířit funkcionalitu z webu, kde registrovaní uživatelé mohou upravovat a rušit své rezervace o možnost, aby administrátoři mohli upravovat všechny rezervace a vytvářet nové pro jiné uživatele. Součástí správy rezervací je i import rozvrhů. Jedná se o jednoduchý formulář, který bude dostupný pouze správcům rezervačního systému. V případě konfliktů bude existovat i proklik na rezervační kalendář se zvýrazněním rezervace nebo rezervací, které jsou v konfliktu s rozvrhem.
4.4 Databáze
Výhodou dat uložených v Obsahu je, že o jejich uložení se stará Umbraco a každý prvek v O bsahu má vlastní unikátní identifikátor. Pro dodatečná data, jako jsou uživatelé, skupiny, slevy a rezervace, je potřeba vytvořit vlastní tabulky v databázi. Na obrázku 4.2 je zobrazen diagram databáze. V levé části jsou naznačena data, která si ukládá Umbraco. Nejedná se o přesnou podobu uložených dat, pouze slouží k naznačení jednotlivých vztahů mezi daty. V pravé části se již nachází reálná podoba databáze.
22 4. Návrh nového rezervačního systému
Obrázek 4.2: Diagram databáze pro nový rezervační systém 23 4. Návrh nového rezervačního systému 4.5 Uživatelské rozhraní
Z uživatelského pohledu by měla být stránka interaktivní. Převážně se jedná o formuláře, které poběží na straně uživatele, proto je snazší vytvořit interaktivní formuláře v Angularu. Dále Webcentrum využívá v Angularu naprogramované komponenty pro vytváření formulářů a Angular samotný podporuje ověření dat před posláním na server, uživatel je tedy dříve upozorněn na chybu ve vyplněných datech a je jednodušší zjistit, kde udělal chybu. Hlavními formuláři jsou: ∙ Rezervační kalendář – Slouží pro zobrazení jednotlivých rezervací v podobě kalendáře. Uživatel může kliknou na volné políčko nebo kliknout a potáhnout myší pro vytvoření rezervace. ∙ Rezervační formulář – Jedná se o vyskakovací okno, které se zobrazí uživateli po vytvoření rezervace v kalendáři. ∙ Registrace uživatele – Slouží k získání základních informací o uživateli. ∙ Upravení profilu uživatele – Jedná se o stejnou komponentu jako při registraci, pouze se liší její konfigurace. ∙ Přihlášení uživatele
Dále je také důležité přizpůsobit tyto formuláře pro mobilní zařízení. Všechny kromě rezervačního kalendáře nebudou potřebovat úpravy, protože naše komponenty ve spojení s jednotným vizuálním stylem nabízí tuto možnost automaticky. Tím, že rezervační kalendář je novou komponentou, je potřeba tuto funkcionalitu doplnit. Rezervační kalendář podporuje týdenní a denní formát, proto chceme, aby se standardně zobrazoval v týdenním formátu, ale pro mobilní zařízení by se měl zobrazit denní formát. Dále také je potřeba vylepšit vytvoření rezervace, protože v původním systému ve vyskakovacím okně se shrnutím rezervace je možnost upravit čas a datum, jak jde vidět na obrázku 4.3. Proto je tato možnost v rezervačním formuláři upravena tak, že uživatel může upravit pouze čas (pomocí tlačítek, které budou přidávat nebo odebírat po půl hodině). Tyto změny v čase se kontrolují a pokud daná rezervace nemůže být vytvořena, tak se čas nezmění. V případě, že chce uživatel změnit datum, tak bude muset zrušit stávající a vytvořit novou rezervaci v daný den. Toto řešení je mnohem pohodlnější pro mobilní zařízení.
24 4. Návrh nového rezervačního systému
Obrázek 4.3: Shrnutí rezervace v původním systému
25 5 Implementace systému
Poté, co byly stanoveny jednotlivé požadavky na systém, probíhala implementace. Proto se v této kapitole podíváme na postup implementace a problémy s ní spojené.
5.1 Webová stránka
Na samotné webové stránce jsou stránky rozděleny do tří skupin, a to stránky přístupné přihlášeným uživatelům, stránky přístupné všem uživatelům a stránky přístupné všem uživatelům, ale po přihlášení se uživatele se jejich chování změní. Stránky, které jsou přístupné pouze přihlášeným uživatelům, jsou pro úpravu jejich profilu nebo změnu hesla. Pro přihlášené uživatele se v hlavičce webu nachází jejich jméno, na které když kliknou, tak jsou přesměrováni na tuto sekci webu. Pro tyto účely máme vytvořený modul, který se stará o ochranu obsahu a pokud uživatel nevyhovuje požadavkům, tak je mu přístup odepřen. V případě, že uživatel není přihlášený, bude přesměrován na stránku, kde se může přihlásit a po přihlášení je přesměrován zpět na stránku, na kterou chtěl přistoupit. Díky tomu, že se jedná o obecný modul pro weby, tak je potřeba definovat skupiny uživatelů a implementovat interface, který se rozhoduje o tom, jestli je uživatel přihlášený a zda má přístup k dané stránce. V našem případě se jedná pouze o skupinu přihlášených uživatelů. Součástí webu je pouze jedna stránka, která mění své chování na základě toho, zda je uživatel přihlášen nebo ne. Jedná se o samotný rezervační kalendář. V takovém případě se rozhodne na straně serveru, zda je uživatel přihlášen a do rezervačního formuláře se pošle potřebná konfigurace. A komponenta v angularu se podle toho přizpůsobí.
5.2 Rezervační kalendář
Kalendář pro vytváření rezervací je velmi složitou komponentou celého systému. Proto není vhodné ji vytvářet od začátku. K dispozici není velké množství komponent, které by vyhovovaly potřebám
26 5. Implementace systému
rezervačního systému. Některé z nich jsou navíc placené. Některé z použitelných komponent jsou celkem větších balíčků a jsou tedy vhodné při vytváření větších systému. Příkladem takového balíčku je jQWidgets1. Jiné nenabízejí přidanou funkcionalitu, která by mohla výt využita při tvorbě nového systému, jako například komponenta od DayPilot2. Cena licencí se pohybuje v řádu stovek dolarů ročně. V kombinaci s tím, že nenabízí funkcionalitu, která by zkvalitnila výsledný systém, není nutné je pro rezervační systém pořizovat. Další část komponent nevhodných k použití jsou ty, které pouze rozšiřují funkcionalitu jiných komponent, protože tato rozšíření nemají praktické využití v rezervačním systému. Proto se do finálního výběru dostaly pouze dvě komponenty a to angular-calendar a fullcalendar. Na první pohled vypadají oba podobně (na obrázku 5.1 je vidět fullcalendar a na obrázku 5.2 zase angular-calendar) a nabízejí podobnou funkcionalitu.
Obrázek 5.1: Ukázka kalendáře vytvořená díky fullcalendar
1. https://www.jqwidgets.com/angular-components-documentation/ 2. https: //code.daypilot.org/30451/angular-calendar-day-week-month-views
27 5. Implementace systému
Obrázek 5.2: Ukázka kalendáře vytvořená díky angular-calendar
Pro porovnání těchto komponent jsem rozdělil jednotlivé funkcionality do tří skupin podle toho, jak se od sebe liší. Na začátku se podíváme na to, co mají jednotlivé komponenty společného, a na konec porovnáme a ukážeme si, v čem se dané komponenty liší. Společné mají to, že se jedná o MIT licenci, která nám umožnuje využít dané komponenty i pro komerční účely. O obě komponenty se vývojáři stále starají, a proto mají desetitisíce stažení týdně (nejedná se o skutečný počet uživatelů, ale má to vypovídající hodnotu o popularitě; více o tom, jak se tento počet stažení počítá naleznete na blogu npmjs3). Fullcalendar je populárnější, protože je dostupný pro více javascriptových frameworků. Na druhou stranu pokud se porovnají pouze verze v angularu, tak je populárnější angular-calendar. Dalším kritériem výběru byla lokalizace, kterou obě komponenty podporují a mají možnost nastavit i formát datumů. Obě komponenty také nabízí možnost skrýt některé dny v týdnu. Tuto funkcionalitu bude potřeba využít u sportovišť, která
3. https://blog.npmjs.org/post/92574016600/ numeric-precision-matters-how-npm-download-counts-work
28 5. Implementace systému
nemají víkendový provoz. Podpora zobrazení jak celého týdne, tak i konkrétního dne je také důležitá. Převážně kvůli podpoře pro mobilní zařízení, u kterých by zobrazení celého týdne bylo nepřehledné a špatně by se s rezervacemi manipulovalo. Pak mají obě komponenty pár věcí společných. Jedná se o takové funkce, které jsou podobné, ale každá komponenta k nim přistupuje trochu jinak. Obě komponenty mají podobnou dokumentaci s ukázkami. Ale angular-calendar k tomu přistupuje trochu jinak a to tak, že každá ukázka má k dispozici i zdrojový kód, takže je mnohem lépe vidět, jak se daná funkcionalita využívá a jak se s ní pracuje. Další podobností je nasazení obou komponent. Fullcalendar kvůli tomu, že se jedná o komponentu pro více javascriptových frameworků, vyžaduje vytvoření objektu, který v sobě obsahuje veškerá nastavení a komponentě se předá tento objekt. Následně se o její vykreslení postará vložený javascript, proto i vzhled jednotlivých částí je možné upravit pouze vytvořením vlastních stylů. Proto zde není ani možnost přidat vlastní styl pouze části komponenty. Na druhou stranu angular-calendar je více přizpůsobitelný díky tomu, že využívá funkcionalitu angularu. Tedy je mnohem jednodušší díky šablonám upravit části komponenty, které budou vypadat jak potřebuji a mohu využít funkcionalitu již vlastních vytvořených komponent. S různým nasazením komponent je spojeno i načítání rezervací pro každý týden zvlášť. Další podobnost je v práci s událostmi, které komponenta zobrazuje. Obě komponenty podporují možnost kliknutí a potáhnutí myší pro vytvoření. Fullcalendar tuto funkcionalitu má zabudovanou, kdežto angular-calendar nabízí část kódu, kterou stačí vložit a nabízí potřebnou funkcionalitu. Výhodou vložení kódu je možnost upravit si tento kód pro vlastní potřeby a vytvořit si vlastní reakci na neplatné vytvoření. Řešení kolizí by se v obou případech řešilo podobně s tím rozdílem, že u fullcalendaru by se předala funkce jako parametr celé komponentě a u angular-calendaru se musí upravit právě vložený kód pro vytváření. Fullcalendar naopak nabízí možnost například otevírací doby, která se dá nastavit pro každý den zvlášť. Nabízí to tedy lepší nastavení kalendáře, ale jedná se o funkcionalitu, která by se možná využila v budoucnu. Angular-calendar nabízí díky šablonám možnost vytvořit si vlastní rozložení jednotlivých prvků komponent a přiřadit jim vlastní styly a nebo jednotlivým částem přiřadit vlastní
29 5. Implementace systému
funkcionalitu. Proto je například jednodušší upravit si horní lištu lépe pro mobilní zařízení. Dále je také umožněno lépe zvýraznit dny, ve kterých je možné vytvořit rezervace. Například před aktuálním dnem a nebo po hraničním datu zašedit dny, aby bylo vizuální odlišení dnů, kdy není možné vytvořit rezervace. Dále je možnost nastavit si vlastní šablonu pro události, takže jim lze přidat vlastní tlačítka. Jedná se o velmi těžké rozhodnutí, kterou komponentu vybrat, protože obě jsou si dost podobné. Přesto angular-calendar nabízí mnohem jednodušší a větší možnosti přizpůsobení nejen vzhledu, ale i funkcionality. Navíc nabízí lepší představení jednotlivých funkcionalit i s ukázkou zdrojového kódu a tedy je jednodušší ho využít v praxi.
5.3 Export rezervací
Důležitou součástí rezervačního systému je i export rezervací pro správce jednotlivých sportovišť a pro ekonomické oddělení, aby mohli vytvořit faktury pro uživatele. V obou případech se jedná o převedení rezervací do nějaké formy tabulky, přičemž uživatel si může zvolit z předem definovaných formátů. Proto za tímto účelem vznikly dvě exportní třídy, které se starají o převod rezervací do tabulky. Obě exportní třídy mají podobnou strukturu, liší se pouze v podobě konstruktoru. Jejich zjednodušenou ukázku můžete vidět na obrázku 5.3. Jako parametr bere rozhraní, díky kterému se může převést obecná forma tabulky do požadované formy. Příklad konkrétního rozhraní můžete vidět na obrázku 5.4. Tato rozhraní jsou v obou případech velmi podobná, přesto není možné vytvořit obecné rozhraní pro oba exporty, protože export pro ekonomické rozhraní je trochu složitější. Práce s těmito exportními třídami je velmi jednoduchá, po jejich vytvoření je potřeba zavolat metodu „Export“ s požadovaným objektem, který implementuje požadované rozhraní. V průběhu této metody se volají funkce rozhraní, které zapisují jednotlivé buňky tabulky. Po skončení této metody obsahuje objekt všechna potřebná data o rezervacích, na základě kterých by měl být schopen vytvořit požadovaný formát dat.
30 5. Implementace systému public class ReservationsExporter { ... public void Export(IReservationsExporter exporter) {...} }
Obrázek 5.3: Ukázka exportní třídy public interface IReservationsExporter { void WriteHeaderField(string value); void EndHeader(); void WriteField(string value); void NewRecord(); }
Obrázek 5.4: Ukázka rozhraní pro export rezervací
5.3.1 Export pro správce Bylo by komplikované všem správcům vytvářet účet v Umbracu, proto je tento export dostupný z webu. Exportování dat lze rozdělit do tří skupin:
∙ Export pro web – Jedná se o zobrazení dat na webové stránce. O jejich zobrazení se stará komponenta vytvořená v angularu. Tato komponenta se také stará o nastavení a následné stažení ostatních dvou formátů.
∙ PDF – Slouží pro spolehlivou výměnu dokumentů, jejichž zobrazení není závislé na softwaru nebo hardwaru. Pro tvorbu těchto dokumentů využíváme knihovnu PDFsharp4. Export do PDF je určen pro tisk, aby správci sportovišť mohli kontrolovat návštěvníky.
4. http://www.pdfsharp.net/?AspxAutoDetectCookieSupport=1
31 5. Implementace systému
∙ CSV – Jedná se o jednoduchý formát pro tvorbu tabulek, který nepodporuje žádné grafické upravení dat. Tento export slouží k dodatečné úpravě rezervací.
5.3.2 Export pro ekonomické oddělení Pro vytvoření faktur pro uživatele je potřeba daná data předat ekonomickému oddělení. Jak jsem psal v podsekci 3.5.1 o původním systému, tak v exportu byly všechny rezervace a pak se musely ručně třídit. Díky možnosti rozdělení uživatelů do skupin a přidělování jim různých slev je možné do výsledného exportu rezervací zahrnou pouze nenulové položky. Možnost exportu je do dvou formátů: ∙ CSV – V původním systému existoval pouze export do tohoto formátu a správce potom ještě tato data graficky upravoval, aby byla přehledná a na ekonomickém oddělení se jim s nimi lépe pracovalo. Tento export je ovšem zachovaný pro případ, kdyby správci nevyhovoval druhý formát. ∙ Office Open XML – Jedná se o formát vytvořený pro Microsoft Excel. Pro vytváření takových dokumentů využíváme .NET knihovnu, která se jmenuje EPPlus5. Knihovna umožnuje jednoduché vytvoření listů a tabulek a jejich uložení do souboru s příponou .xlsx. Export do tohoto formátu je hlavní, protože umožňuje vytvoření přehledné tabulky, kterou už není potřeba upravovat před posláním na ekonomické oddělení. Grafická podoba dat pak vychází z toho, jak správce pokaždé upravoval data v původním rezervačním systému.
5.4 Import rozvrhů
Rozvrhy se vyplňují v Informačním systému Masarykovy univerzity (IS). Importování rozvrhů je rozděleno do dvou typů podle toho, jestli probíhají automaticky nebo ručně. Rozvrhy se nejprve importují ručně ještě před jejich zveřejněním kvůli tomu, aby se mohly vyřešit konflikty s rozvrhem v ISu. Některé rezervace nemohou být zrušené, a proto se kvůli nim musí změnit rozvrh. Většinou se však konflikty řeší na
5. https://github.com/JanKallman/EPPlus
32 5. Implementace systému
straně rezervačního systému tím, že se již naplánované rezervace zruší. Když proběhne importování rozvrhů v pořádku a rozvrh je již ve své finální verzi, tak se posune hraniční datum sportovišť před začátek následujícího semestru. Pro aktuální semestr probíhá importování rozvrhů automaticky každý den. Slouží ke kontrole, jestli nenastaly nějaké změny v rozvrhu a informuje správce pomocí e-mailu v případě konfliktů. Rozvrhy je možné z ISu importovat ve dvou formátech, které jsou vhodné pro další zpracování programem. Prvním formátem je Extensible Markup Language (XML). Jedná se o značkovací jazyk, který se využívá ke sdílení široké škály dat na internetu. Pokud bych chtěl importovat rozvrhy z XML, musel bych daný text v XML převést na objekty a dále z těchto objektů vytvořit jednotlivé položky, které by odpovídaly rezervacím v rezervačním systému. Právě převod těchto objektů na rezervace by byl složitý a vyžadoval by vlastní algoritmus na vytvoření rozvrhu. Na obrázku 5.5 se nachází ukázka kódu, ze kterého jsme schopni zjistit v jaký den v týdnu a v kolik hodin se daný předmět vyučuje, ale omezující podmínky se nacházejí až v poznámce s identifikačním číslem 23. Na obrázku 5.6 je další ukázka kódu,ze které můžeme vyčíst, že daný slot je platný pouze 30. 10. Úmyslně jsem zvolil tento příklad, protože tato poznámka se objevuje ve více slotech, proto by bylo obtížnější z daných poznámek získávat potřebné omezující podmínky. Z tohoto důvodu jsem zvolil pro import rozvrhů druhý formát, kterým je iCalendar. V RFC číslo 5545 [14] se dočteme, že se jedná o standard, který slouží pro výměnu kalendářových dat mezi různými aplikacemi nebo systémy. Byl založen pro rozšíření typů internetových médií, což umožnilo výměnu různými způsoby jako například SMTP, HTTP a nebo pomocí některých bezdrátových technologií. Přesto se jedná o formát, který je nezávislý na protokolech nebo kalendářových systémech. Díky tomuto formátu je možné rozvrhy importovat i do jiných kalendářových systému jako je například Google Kalendář. Díky tomu, že se jedná o standard, existuje balíček, který se jmenuje Ical.Net. Tento balíček je schopen zpracovat data pomocí standardu a vytvořit jednotlivé události, které odpovídají jednotlivým položkám kalendáře. Události je velmi snadné převést na rezervace, protože jedna událost odpovídá jedné rezervaci.
33 5. Implementace systému
Obrázek 5.5: Ukázka rozvrhu ve formátu XML
Obrázek 5.6: Ukázka poznámky k rozvrhu
34 5. Implementace systému
Samotný proces importu je pro oba typy importu stejný. Stáhnou se aktuální rozvrhy z ISu pro jednotlivé místnosti, srovnají se s rozvrhem, který se již nachází v rezervačním systému a následně se naleznou změny mezi těmito dvěma rozvrhy. Pokud daná rezervace neexistuje v rozvrhu, tak se ze systému odstraní. Pokud se pouze změnil její název, tak se upraví v databázi. Pokud se jedná o novou položku rozvrhu, tak se jí nastaví stejný speciální uživatel, který se jmenuje „systém“. Následné změny se vloží do databáze. Největším problémem tohoto importu je, že získání rozvrhu z ISu trvá podle jeho složitosti. U nejsložitějších se jedná zhruba o 2 minuty. Pokud by získávání těchto rozvrhů z ISu nebylo paralelní, mohl by celý proces zabrat i více než deset minut. U automatického importu rozvrhů by to nebyl problém, ale při ručním importu by musel správce poměrně dlouho čekat. Proto se pro zrychlení práce s importováním rozvrhů získávají rozvrhy paralelně.
5.5 Import dat ze starého systému
Pro zálohování nebo přenos dat mezi databázemi se využívá SQL dump. Jedná se o soubor, který v sobě obsahuje příkazy na vytvoření tabulek, příkazy na vložení dat i příkazy na vytvoření spouští k daným tabulkám. Tento soubor může obsahovat celou databázi, nebo jen vybrané tabulky. Jak jsem již psal v sekci 3.6 původní systém běžel na databázi MySQL, ale nový systém poběží na Microsoft SQL Server (viz sekce 2.4). Oba dva databázové systémy nabízejí implementaci jazyka SQL, jsou však malinko odlišné, proto nelze využít přímo kód pro MySQL bez úprav v našem systému. Naštěstí změny se týkají pouze vytváření tabulek a příkazu pro vložení dat. Před importem dat do nového systému byly vytvořeny potřebné pomocné tabulky, které odpovídaly struktuře dat z původního systému a do těchto tabulek byla data vložena. Následně byly vytvořeny další pomocné tabulky, které sloužily k mapování starých identifikátorů na nové, například u sportovišť nebo areálů. Po úpravách, které jsou popsané níže, byla data importována do nového systému.
35 5. Implementace systému
Do nového systému byli přeneseni pouze uživatelé, kteří si nezrušili svůj účet. Samotný proces byl velmi jednoduchý, protože se přenášela data 1:1. Jedno z mála, co se upravovalo, bylo heslo. Kvůli tomu, že neznáme algoritmus, jakým způsobem původní systém vytvářel otisky hesel, všem uživatelům se nastavil prázdný řetěz. Při prvním pokusu o přihlášení se uživatele po spuštění nového systému bude vyzván, aby si resetoval heslo. Zároveň mu bude zaslán e-mail s odkazem, kde si bude moci zvolit nové heslo. Tento odkaz platí vždy pouze hodinu. Celkově bylo přeneseno zhruba dva tisíce uživatelů. Před samotným importem ještě byli odebráni uživatelé s duplikátním e-mailem, taková situace není možná v novém systému a tudíž by vznikaly problémy. Přenos rezervací byl složitější, protože v původním systému bylo veliké množství rezervací (řádově několik desetitisíců). První selekce proběhla již v textové podobě, kdy pomocí regulárního výrazu byly odstraněny rezervace před rokem 2020. Zbylé rezervace byly importovány do pomocné tabulky, kde se s nimi dále pracovalo. Následně byly odstraněny rezervace, které proběhly před spuštěním systému. Pro přiřazení nového identifikátoru musel být využit e-mail z toho důvodu, že jsme neměli jinou možnost, jak propojit identifikátor ze starého systému s novým identifikátorem uživatele. Nejsložitějším procesem byla snaha zachovat hromadné rezervace, protože po přenosu do nového systému se změní identifikátory jednotlivých rezervací. Navíc z důvodů selekce rezervací mohlo dojít k tomu, že rodičovská rezervace byla odstraněna při selekci. Rodičovská rezervace je taková, která má stejný vlastní identifikátor s identifikátorem rodiče a její identifikátor mají nastavený ostatní rezervace jako rodičovský. Proto ještě před úpravou byla potřeba rezervacím, kterým neexistovala rodičovská rezervace, vybrat novou existující rezervaci, která bude rodičovská. Následný import pak měl tři kroky:
1. Nejprve se importovaly rodičovské rezervace pro hromadné rezervace, abych jim po importu mohl nastavit identifikátor rodiče na jejich nový identifikátor.
2. V dalším kroku byly importovány ty rezervace, které neměly nastavený identifikátor rodiče.
36 5. Implementace systému
3. Na závěr byl importován zbytek hromadných rezervací, kterým se nastavil identifikátor rodiče na již nový identifikátor.
37 6 Závěr
Hlavním výsledkem práce je vytvoření nového systému, který byl úspěšně spuštěn v říjnu 2020 i s veškerými importovanými daty z původního systému. Týden běžely oba systémy současně, aby si správci mohli nový systém vyzkoušet a pomohli tak odhalit nedostatky systému. Důležitým výsledkem práce je, že nový systém již běží pod správou týmu Webcentra, což umožnuje dále systém přizpůsobovat současné situaci. Například, jak bylo v roce 2020 využito, možnost zavření celého systému pro veřejnost z důvodů zavření sportovišť kvůli pandemické situaci a vyhlášenému nouzovému stavu. Podařilo se zjednodušit export rezervací pro ekonomické oddělení, který už není potřeba upravovat. V budoucnu by bylo dobré propojit rezervační systém s Obchodním centrem MU, který by uživatelům nabídl možnost zaplatit rezervaci online a ekonomickému oddělení tímto zmenšit administrativu. Webcentrum nabízí možnost propojení, ale je nutné, aby se FSpS domluvila s Obchodním centrem o vytvoření a nastavení potřebných údajů. V neposlední řadě se povedlo propojit rezervační systém s ISem. Zaprvé se podařilo zautomatizovat import rozvrhů získávaných z ISu, díky čemuž nemůže dojít ke konfliktům mezi rozvrhem a rezervačním systémem. Zároveň dochází ke každodenní kontrole změn v rozvrhu. Dále se povedlo využít jednotné přihlášení k přihlášení uživatelů. V budoucnu chceme využít jednotné přihlášení i k registraci, což uživatelům umožní ji zjednodušit a vyhnout se vytváření dalšího hesla. Současně celý web přešel pod jednotný vizuální styl univerzity, což umožní i v budoucnu dodržovat jednotný styl při jeho případných změnách.
38 Bibliografie
1. Get started with .NET Framework [online] [cit. 2020-09-25]. Dostupné z: https://docs.microsoft.com/en- us/dotnet/ framework/get-started/. 2. ASP.NET overview [online] [cit. 2020-10-03]. Dostupné z: https: //docs.microsoft.com/en-us/aspnet/overview. 3. GALLOWAY, Jon; WILSON, Brad; ALLEN, K. Scott; MATSON, David. Professional ASP.NET MVC 5. Wiley, 2014. ISBN 9781118794753. 4. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, Shashank et al. Database system concepts. 6th. McGraw-Hill New York, 2010. ISBN 0-07-352332-1. 5. Databases [online] [cit. 2020-10-07]. Dostupné z: https : / / docs . microsoft . com / en - us / sql / relational - databases / databases/databases?view=sql-server-2017. 6. TANENBAUM, Andrew S.; WETHERALL, David et al. Computer networks. 5th. Prentice hall, 2011. ISBN 0-13-212695-8. 7. What is JavaScript? [online] [cit. 2020-10-25]. Dostupné z: https: / / developer . mozilla . org / en - US / docs / Web / JavaScript / About_JavaScript. 8. SPA (Single-page application) [online] [cit. 2020-10-27]. Dostupné z: https://developer.mozilla.org/en-US/docs/Glossary/ SPA. 9. What is TypeScript? [online] [cit. 2020-10-01]. Dostupné z: https: //www.typescriptlang.org/. 10. Introduction to Angular concepts [online] [cit. 2020-10-10]. Dostupné z: https://angular.io/guide/architecture. 11. What is the DOM? [online] [cit. 2020-11-01]. Dostupné z: https: //developer.mozilla.org/en-US/docs/Web/API/Document_ Object_Model/Introduction. 12. FIELDING, Roy T.; RESCHKE, Julian. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content [RFC 7231]. RFC Editor, 2014. Dostupné z DOI: 10.17487/RFC7231. RFC.
39 BIBLIOGRAFIE
13. ARLOW, Jim; NEUSTADT, Ila. UML a unifikovaný proces vývoje aplikací: průvodce anyálýzou a návrhem objektově orientovaného softwaru. Computer Press, 2003. ISBN 80-7226-947-X. 14. DESRUISSEAUX, Bernard. Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC 5545]. RFC Editor, 2009. Dostupné z DOI: 10.17487/RFC5545. RFC.
40 A Elektronické přílohy
Příloha obsahuje zdrojový kód rezervačního systému. Vzhledem k tomu, že rezervační systém byl integrován do redakčního systému Umbraco, nemůže být z tohoto zdrojového kódu vytvořena samostatná aplikace. Zdrojový kód rezervačního systému je rozdělen do dvou složek:
∙ /client – obsahuje veškerý kód napsaný v Angularu
∙ /server – obsahuje veškerý kód napsaný v C# a Razoru.
41