Informační systém tenisového klubu SKT Tišnov

Mendelova univerzita v Brně Provozně ekonomická fakulta

Informační systém tenisového klubu SKT Tišnov Bakalářská práce

Vedoucí práce: Ing. Pavel Turčínek

Pavel Fiala

Brno 2013

Zde bych chtěl poděkovat Ing. Pavlu Turčínkovi za ochotu při vedení této práce a poskytování cenných rad, které vedly k jejímu úspěšnému dokončení.

Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně s použitím literatury, která je uvedena v seznamu dále. V Brně dne 20. května 2013

_________________

Abstract Fiala, P. Information system of the SKT Tišnov tennis club. Bachelor thesis. Brno, 2012. This thesis describes the analysis, design and implementation of the Information system of the SKT Tišnov tennis club. The first part is devoted to the theory, which is explaining the basic concepts and issues of information systems. Then the analysis of information flows of the tennis club is made and the consecutive design of the system is created. After that implementation using advanced web technologies is realized. Finally, it tries to evaluate the benefits of the created system for the SKT Tišnov tennis club. Keywords Information system, tennis club, CASE tools, Nette framework, PHP, MySQL

Abstrakt Fiala, P. Informační systém tenisového klubu SKT Tišnov. Bakalářská práce. Brno, 2012. Tato bakalářská práce popisuje analýzu, návrh a implementaci Informačního systému tenisového klubu SKT Tišnov. První část práce je věnována teorii, kde jsou objasňovány základní pojmy a problematika informačních systémů. Dále je provedena analýza informačních toků tenisového klubu a vytvořen následný návrh systému. Poté je realizována implementace za pomocí moderních webových technologií. Nakonec se snaží zhodnotit přínosy vytvořeného systému pro SKT Tišnov. Klíčová slova Informační systém, tenisový klub, CASE nástroj, Nette Framework, PHP, MySQL

6

Obsah

Obsah 1

Úvod a cíl práce

9

1.1

Úvod ...........................................................................................................9

1.2

Cíl práce .....................................................................................................9

2

Základní pojmy problematiky informačních systémů

10

3

Informační systémy

11

3.1

Etapy životního cyklu IS .......................................................................... 11

3.2

Analýza a návrh IS ................................................................................... 12

3.2.1 3.3

4

5

Typy přístupů k analýze ................................................................... 12

Strukturovaná analýza............................................................................. 12

3.3.1

Základní modely strukturované analýzy ......................................... 12

3.3.2

Data Flow Diagram (DFD) .............................................................. 12

3.3.3

Entity Relationship Diagram (ERD) ............................................... 13

3.3.4

Další podpůrné prostředky strukturované analýzy......................... 13

Programové prostředky pro realizaci

15

4.1

Prostředky využité při analýze ................................................................ 15

4.2

Prostředky využité při implementaci ...................................................... 15

4.2.1

Framework Nette ............................................................................. 15

4.2.2

PHP .................................................................................................. 17

4.2.3

SQL a MySQL................................................................................... 18

4.2.4

HTML5 ............................................................................................. 18

Analýza a návrh stávajícího IS

19

5.1

Průzkum a struktura klubu ..................................................................... 19

5.2

Neformální specifikace ............................................................................ 19

5.3

Funkční požadavky .................................................................................. 19

5.4

Hardwarové a softwarové požadavky..................................................... 20

5.5

Shrnutí .................................................................................................... 20

5.6

Strukturovaná analýza............................................................................ 20

Obsah

6

7

5.6.1

Kontextový diagram ......................................................................... 21

5.6.2

Systémový diagram ......................................................................... 22

5.6.3

Entitně relační diagram .................................................................. 24

Implementace

27

6.1

Uživatelské rozhraní ............................................................................... 27

6.2

Autentizace uživatele .............................................................................. 29

6.3

Rezervace ................................................................................................ 30

6.4

Družstva, statistiky a platby ................................................................... 32

7

Závěr a přínosy systému

35

8

Literatura

36

8

Seznam obrázků

Seznam obrázků Obr. 1 Zjednodušený diagram architektury klient / server (Althammer, Pree, 2001).

16

Obr. 2

Architektura MVC (Selfa a kol., 2006).

16

Obr. 3

Kontextový diagram tenisového klubu SKT Tišnov

22

Obr. 4

Systémový diagram tenisového klubu SKT Tišnov

23

Obr. 5

Entitně relační diagram tenisového klubu SKT Tišnov

25

Obr. 6

Rozložení stránky pomocí drátěného modelu

28

Obr. 7

Funkce autentizace uživatele

30

Obr. 8 Přehled rezervací dvorců při přihlášení uživatele s rolí pouze hráče Obr. 9

32

Přehled družstev při přihlášení uživatele s rolí pouze hráče33

Úvod a cíl práce

9

1 Úvod a cíl práce 1.1

Úvod

V současné době patří mezi základní stavební kameny úspěšného podniku kvalitní informační systém. Zatímco velké a střední podniky si vybírají z komfortní nabídky informačních systémů vytvořenými profesionály, ty menší podniky a neziskové organizace si často tento luxus nemohou dovolit. Sahají často k levnějším alternativám nebo informační systém nevlastní vůbec. Nejvíce tímto nedostatkem trpí právě malé neziskové organizace, jako je i sportovní klub Tenis Tišnov (SKT Tišnov). Vznik tohoto tenisového klubu sahá daleko do historie. První tenisový klub v Tišnově byl založen pod názvem LTC Tišnov už v roce 1922. I přes mnoho překážek v růstu a vývoji v podobě Druhé světové války a dalších se klub v roce 1992 stává samostatným právním subjektem, avšak s ostatními sportovními kluby v Tišnově pod společnou střechou SSK Tišnov, který byl přímým nástupcem bývalé tělovýchovné jednoty. Dnes se klub může těšit ze 120 evidovaných členů, kteří mohou využívat solidní zázemí se čtyřmi tenisovými dvorci, z toho dva jsou v zimním období překryty nafukovací halou.

1.2 Cíl práce Cílem této práce je vytvořit informační systém pro tenisový klub SKT Tišnov. Tento informační systém bude vytvořen přímo dle požadavků členů klubu a zároveň bude sloužit i jako rezervační systém tenisových dvorců klubu. Po získání veškerých požadavků na systém, bude provedena strukturovaná analýza pomocí CASE nástroje PowerDesigner. Dle této analýzy bude pak zhotoven návrh informačního systému, představován ER diagramem. Daný návrh bude naimplementován jako webová aplikace pomocí Frameworku Nette, skriptovacího jazyka PHP a databázového systému MySQL. Závěrem této práce budou zhodnoceny přínosy pro samotný klub SKT Tišnov.

10

Základní pojmy problematiky informačních systémů

2 Základní pojmy problematiky informačních systémů Nejprve než přistoupíme k samotné problematice informačních systémů, je nutné si definovat některé základní pojmy. • Informace vznikají z dat až v okamžiku jejich použití uživatelem. Pro uživatele mají určitý význam a uspokojují jeho konkrétní objektivní informační potřebu. • Systém je množina prvků a množina vazeb mezi nimi, jež jako celek vykazuje určitou funkci. • Informační systém (IS) je komplex informací, lidí použitých informačních technologii, organizace práce, řízení chodu systému a konečně technických prostředků a metod sloužících ke sběru, přenosu, uchování a dalšímu zpracování dat za účelem tvorby a prezentace informací. • Informační technologie (IT) reprezentují technické, programové a metodické prostředky, kterých se využívá k pořízení, uchování, zpracování, prezentaci a přenosu dat. • IS/IT (IS/ICT) lze vysvětlit následovně. Zatímco IS reprezentuje potřebu informací, IT (ICT1) uspokojení této potřeby (Rábová, 2008).

1

Zkratka ICT reprezentuje Informační a komunikační technologie.


11

3 Informační systémy Nejprve se budeme zabývat životním cyklem informačního systému a jeho etapami. Pojem životní cyklus vývoje IS je spojen s procesem tvorby informačního systému. Ten je zahájen primární myšlenkou něco upravit či zlepšit prostřednictvím IS/IT daného podniku a končí, když se vytvořený IS přestane používat. Nicméně toto vymezení je pouze prostý pohled na danou problematiku, ve skutečnosti se životní cyklus skládá z více etap s různou složitostí.

3.1 Etapy životního cyklu IS • Specifikace problému – jedná se o úvodní etapu vývoje IS, která se zabývá požadavky zadavatele a uživatelů systému. Součástí by měla být také studie realizovatelnosti projektu, která dává odpověď, zda má vůbec smysl problém začínat řešit. Výstupem této etapy je také několik dokumentů např. Zadání projektu a Specifikace požadavků. • Analýza a návrh – zde se z obecných požadavků stávají detailnější funkční a datové požadavky na daný systém. Poté jsou vyobrazeny v konceptuálním modelu jako návrhy funkcí a datových struktur. Hlavní systém bývá dekomponován na dílčí subsystémy, definují se jejich funkcionality a také vztahy mezi nimi. Výsledkem je pak tzv. logický model systému. Návrhová část je podpořena hrubou verzí technologického modelu a pro zvolenou variantu technického a programového vybavení, tzv. výchozí technologický model systému. • Implementace – v této části se provádí programová realizace softwarových součástí, vzniká tzv. implementační model. Dále se vytváří dokumentace, připravuje se konverze dat nebo jiný způsob vkládání dat do databáze a uskutečňují se testy implementovaných součástí. • Zavedení – základem této etapy je instalace technického a programového vybavení. Uskutečňuje se zde zmiňovaná konverze dat nebo jejich vložení do databáze jiným způsobem a rovněž zaškolení uživatelů. Proces zavedení by měl být celý proveden bezpečně, v co nejkratším čase a co nejvíce uživatelsky nenáročný. Nepochybně je nutné zavést zpočátku pouze zkušební provoz a až po úspěšném provedení všech schvalovacích testů lze přejít na běžný provoz. • Provoz, údržba a rozvoj produktu – cílem je zajistit bezproblémový provoz, průběžné aktualizace, zajištění bezpečnosti dat, údržba nejen programového systému, ale také aktualizace dokumentace a realizace změn (Rábová, 2008; Molnár, 2009). Analýza a návrh IS budou ještě podrobněji popsány v následující kapitole.

12


3.2 Analýza a návrh IS Jde o jednu z nejdůležitějších etap životního cyklu vývoje informačního systému. Výstupem této etapy je model systému, který obsahuje více různých diagramů, podnikových pravidel, specifikací procesů a doplňkových dokumentů. 3.2.1

Typy přístupů k analýze

• Strukturovaný přístup • Objektově orientovaný přístup Strukturovaný přístup využívá dva základní modely, funkční, který popisuje funkce v systému a transformace dat a datový reprezentující strukturu dat v databázi. Oba tyto modely by měli být konzistentní, každá změna v jednom z nich by se měla projevit i v druhém modelu. Objektově orientovaná analýza využívá prostředků jazyka UML. Data i funkce jsou rozebírány společně s pomocí zcela jiných modelů a diagramů (Molnár, 2009) V této práci bude využíváno prostředků strukturovaného přístupu k analýze a návrhu IS, který bude v následující kapitole blíže popsán.

3.3 Strukturovaná analýza 3.3.1 1.

Základní modely strukturované analýzy

Funkční model Ukazuje funkce systému, toky dat mezi funkcemi systému a jejím okolím, toky dat mezi funkcemi systému a data ukládaná v systému. Bývá reprezentován Data Flow Diagramem (DFD).

2.

Datový model Zobrazuje datové entity, jejich atributy a statické vztahy mezi nimi. Hraje zásadní roli při návrhu databáze daného systému. K jeho zobrazení je používán diagram entit a vztahů – ERD (Entity Relationship diagram).

3.

Model dynamického chování systému Pro jeho modelování se využívá stavový diagram (State Transition Diagram), ve kterém jsou zachyceny stavy, v nichž se systém nebo jeho část může nacházet. Avšak tento model nachází svoje častější využití v objektové analýze, kde reprezentuje objekty s nápadným dynamickým chováním (Rábová, 2008).

3.3.2

Data Flow Diagram (DFD)

Tato technika se využívá při strukturované analýze a návrhu pro zachycení chování systému a jeho funkcionality. Obsahuje 4 typy prvků:


13

• Procesy – provádějí transformaci dat vstupních na data výstupní • Datové toky – vyjadřuje přesun dat nebo informací z jedné části systému do jiné. • Terminátory – znázorňují objekt vně systému, s nímž systém komunikuje. Může to být člověk, skupina lidí nebo oddělení, popřípadě jiný systém. • Datastory – jedná se o místo dočasného uchování dat pro jejich pozdější využití. Používá se tam, kde mezi procesy existuje časové zpoždění při předávání dat. Primárním principem této technologie je dekompozice, tedy rozklad komplexního problému na dílčí jednodušší. Většinou se dekomponují procesy na subprocesy a někdy také toky na subtoky. DFD se může zdát podobný Use Case Diagramu (UCD) z objektové analýzy a návrhu. Nicméně nacházejí se zde i zmiňované datastory a toky dat mezi nimi a funkcemi systému. Bývá zvykem, že procesy na nejnižší úrovni v diagramu datových toků jsou blíže popsány tzv. minispecifikací. Ta blíže specifikuje funkci daného procesu prostřednictvím strukturovaného textu. 3.3.3

Entity Relationship Diagram (ERD)

Zcela se odlišuje od diagramu datových toků, který charakterizuje funkce, které systém má vykonávat. ERD totiž modeluje data, které je nutné v systému uchovávat a vztahy mezi nimi. Pomocí tohoto modelu lze poté snadno navrhnout strukturu databáze určeného systému. Důležité pojmy k datovému modelování: • Entita – věc reálného světa, musí byt jedinečná • Entitní množina – skládá se z entit stejného typu, které sdílí stejné atributy • Vztah – vyjadřuje stav, kdy spolu dvě entity souvisejí, je mezi nimi nějaká logická vazba. Každý vztah deﬁnuje své jméno, členství2 entity v daném vztahu, kardinalitu3 a název role, kterou příslušná entita hraje v určitém vztahu. • Atribut – vlastnost entity, která je pro nás v dané souvislosti důležitá (Molnár, 2009). 3.3.4

Další podpůrné prostředky strukturované analýzy

Kromě uvedených nástrojů strukturovaného přístupu existují i další prostředky doplňující základní diagramy a detailněji popisující danou analýzu, popřípadě návrh systému.

Jde o minimální počet vztahů daného typu, na kterých se musí podílet jedna entita, typické hodnoty jsou 1 – povinný, 0 – volitelný. 3 Je to maximální počet vztahů daného typu, ve kterých může participovat jedna entita. 2

14

1.


Datový slovník (Data Dictionary) Obsahuje veškeré datové prvky celého systému, které jsou společné funkcím a datovým modelům.

2.

Životní cyklus entity (Entity Life History, ELH) V některých metodikách slouží jako kontrola konzistence mezi DFD a ERD. Modeluje všechny možné kombinace, které mohou nastat pro výskyt dané entity během její existence v informačním systému. Může být vytvořen pro každou entitu obsaženou v ERD. Běžně se však příliš nepoužívá, z tohoto důvodu nebude v této práci dále rozebírán.

3.

Matice CRUD Jednotlivé písmena názvu reprezentují vztah procesů s datastory nebo vztah procesů s datovými prvky ve funkčním modelu systému (C – vytváření, R – čtení, U- aktualizace, D - mazání). Ve strukturované analýze se často využívají pro svou jednoduchost a názornost.

Někdy bývají k analýze systému připojena i podniková pravidla. Jedná se o obecně používaná pravidla v podniku např. podnikové směrnice, vládní nařízení, požadavky zákazníků apod. Jsou popisována iterativně, od jednoduchého po detailní a zcela konkrétní vyjádření. Existují ve více typech: • Definice – zákazník je identifikován jménem a adresou • Skutečnost – klient může založit jednu nebo více objednávek • Vzorec – cena objednávky se rovná součtu cen jednotlivých položek • Omezení – suma poptávky celkem nesmí přesáhnout částku 1 mil Kč Za zmínku stojí i tzv. domény, které se přiřazují k datovým prvkům a podporují snazší identifikaci typu informace v daném projektu. S jejich pomocí je zjednodušena standardizace datových charakteristik a tvorba přehledných a srozumitelných modelů (Rábová, 2008; Molnár, 2009).


15

4 Programové prostředky pro realizaci 4.1 Prostředky využité při analýze Velmi mocným nástrojem pro vývoj informačních systémů jsou CASE nástroje. Jedná se o nástroje, které lze využít prakticky ve všech etapách projektu. Díky tomu může na jednom projektu spolupracovat zároveň více pracovníků a sdílet rozpracované části. Mezi primární funkce CASE nástrojů patří modelování IS pomocí diagramů, generování zdrojového kódu z modelu, zpětné generování modelu ze zdrojového kódu a vytvoření dokumentace k danému modelu. • PowerDesigner se stal prvním CASE nástrojem, který kompletně zahrnuje všechny stránky rozvoje podniku. Obsahuje nástroje pro procesní analýzu, které určují důležité funkce podniku a také má integrované prostředí pro datovou a objektovou analýzu informačních systémů.

4.2 Prostředky využité při implementaci 4.2.1

Framework Nette

Framework obecně lze popsat jako softwarovou strukturu, která vývojáři či programátorovi umožní soustředit se pouze na konkrétní problémy bez toho, aby opakovaně programoval typické situace dané oblasti. Obsahuje různé podpůrné programy, knihovny API a další nástroje usnadňující práci. Frameworky bývají založené na architektuře MVC, která v posledních letech dramaticky nabírá na popularitě, což je nejspíš způsobeno tím, že jednotlivé technologie již mají ranou fázi vývoje za sebou a vedle základních nástrojů se tak snaží nabídnout i prostředky pro tvorbu aplikací s kvalitní architekturou. Zend (2012) proto investuje nejen do PHP samotného, ale i do Zend Frameworku. Microsoft proto vytvořil nový webový framework ASP.NET/MVC (2012) a i dalších nezávislých tvůrců MVC frameworků pro různé technologie jsou stovky. Mnoho moderních aplikací používá klient-server architekturu, která zhruba odpovídá schematickému znázornění na obrázku 1. Klient přistupuje a manipuluje s daty v datovém úložišti, které je uloženo na serveru. Klient může být rozdělen na komponentu model a zobrazení (view), kde model odpovídá určité obchodní logice na straně klienta a zobrazení vizuální reprezentaci modelu. Server se skládá z aplikačního serveru, který obsahuje model, na straně serveru a úložiště dat, které zahrnuje databázi.

16

Obr. 1


Zjednodušený diagram architektury klient / server (Althammer, Pree, 2001).

Paradigma Model View Controller bylo původně určeno pro uživatelské rozhraní v aplikacích realizovaných Smalltalkem, ale od té doby se stalo vzorem pro návrh uživatelských rozhraní bez ohledu na implementační jazyk a pro webové aplikace, jejichž ovládací prvky se často mění (Selfa a kol., 2006). MVC architektura je znázorněna na obrázku 2, interaktivní systém se rozděluje do tří složek, kde každá z nich se specializuje na svoji úlohu. Model obsahuje aplikační data a řídí základní funkce. View (zobrazení) řídí vizuální zobrazení modelu a zpětnou vazbu pro uživatele. Controller (ovladač) interpretuje vstupy z myši a klávesnice od uživatele, řídí model a pohled a iniciuje případné změny (Selfa a kol., 2006).

Obr. 2

Architektura MVC (Selfa a kol., 2006).

Controller má přímý odkaz na Model, aby mohl upravit jeho data, View má přímý odkaz na Model, aby mohl jeho data zobrazit.


17

Ačkoliv MVC jako celek řeší prezentační vrstvu aplikace, pouze dvě komponenty mají přímo na starost prezentační funkcionalitu - jsou to View a Controller. Toto jsou také komponenty, které se v jednotlivých variacích liší, zatímco Model je stále stejný, a proto je vhodné k němu uvést pár poznámek: Nejčastější chybou je, že za modelem vidí pouze sadu datových objektů (možná proto, že v data-centrickém programování se „datový model“ skutečně orientuje primárně na datové struktury). Model ve smyslu MVC je však daleko víc, je to tzv. doménový model, který modeluje vztahy reálného světa. V něm jsou kromě dat důležité i další věci, jako například business pravidla („zákazník může otevřít novou objednávku až po zaplacení minulé faktury“) nebo validační pravidla („jméno je povinná položka“). Některé technologie svádí k definici doménových pravidel ve view, v architektuře MVC však správně patří do modelu. Důvod je ten, že jednotlivá pravidla typicky potřebujeme ve více pohledech současně (např. při vytvoření nového zákazníka a pak při jeho editaci), a jejich uložení ve view by znamenalo nutnost duplikace. O modelu se většinou mluví v jednotném čísle, i když je obvykle realizován více objekty. V klasickém třívrstvém modelu, kde máme datovou, aplikační a prezentační vrstvu, model v prezentační vrstvě v principu odpovídá modelu v aplikační vrstvě. Bohužel není zcela obvyklé, aby nástroje uměly tyto modely synchronizovat - tento úkol je tak většinou na bedrech programátora. Další informace o architektuře MVC a její aplikaci představují ve svých publikacích Watanabe a kol. (2009) nebo Castellano a kol. (2004). Informační systém, o kterém tato práce pojednává je naimplementován pomocí Frameworku Nette, jehož autorem je David Grudl. U Nette jsou obdobou kontrolerrů tzv. presentery, staví tedy na architektuře MVP (Model-ViewPresenter). Jedním z hlavních důvodů výběru právě Frameworku Nette je jeho dnes již velice solidní dokumentace a komunita. 4.2.2

PHP

PHP je široce používaný skriptovací jazyk, který je obzvláště vhodný pro vývoj webových aplikací, má volně šiřitelnou licenci, obrovskou podporu na hostingových službách a mnoho dalších výhod. Počátky tohoto jazyka spadají do roku 1994, kdy se pan Rasmus Lerdorf rozhodl vytvořit jednoduchou aplikaci, napsanou v jazyce PERL, která sloužila k počítání přístupů na jeho stránky. Později byla tato aplikace přepsána do jazyku C, protože kód v PERLu příliš zatěžoval server. Název PHP: Hypertext Preprocessor vznikl s novou verzí PHP 3, kterou připravil Rasmus s novými kolegy – Andim Gutmansem a Zeev Suravskim. Součástí této verze bylo nové rozhraní API, které obsahovalo např. spojení s databází, kontrolu pravopisu a další rozšíření. Koncem roku 1998 Andi a Zeev dospěli k názoru, že lze PHP napsat mnohem lépe. Proto přišla oficiálně roku 2002 verze PHP 4, která zastávala nový přístup – „nejprve překlad, pak zpracování“. Zásluhou tohoto přístupu se jazyk

18


stal o mnoho výkonnějším, aniž by došlo k narušení zpětné kompatibility s PHP 3. Poté byly díky některým změnám vydány dílčí verze 4.1.0, 4.2.0 a 4.3.0 obsahující např. superglobální proměnné ($_GET, $_POST apod.), rozhraní příkazového řádku a výrazně vylepšené proudové zpracování síťových a souborových vstupů. Následující verze PHP 5 přináší nový objektově orientovaný model, ve kterém proměnné pracují s odkazy na objekty, není nutné předávat objekty funkcím odkazem. To stejné platí o přiřazování objektů proměnným. Nachází se zde také nové objektově orientované funkce – modifikátory public, private, protected, název konstruktoru _construct(), název destruktoru _destructor, statické metody, abstraktní třídy a metody, funkce na ošetření výjimek a mnoho dalších ( Gutmans, Andi a kol., 2005). 4.2.3

SQL a MySQL

Jazyk SQL spadá do deklarativních programovacích jazyků a slouží k manipulaci s daty uloženými v databázi. Jedná se o neprocedurální4 jazyk, který byl navržen způsobem, aby se co nejvíce shodoval s běžným jazykem. SQL je základem pro relační databázový systém MySQL, který je v této práci použit pro manipulaci s databází. Jelikož se jedná o velmi rychlý, multiplatformní a především volně šiřitelný databázový systém, stal se jedním z nejpoužívanějších. 4.2.4

HTML5

Jde se o rozšířenou specifikaci značkovacího jazyka HTML. Původní HTML má kořeny hluboko v historii. Jeho první návrh byl poprvé zveřejněn v roce 1993. Poté byly postupně vyvíjeny verze 2.0, 3.2 a 4.0 a zanedlouho konečně verze 4.01. V průběhu jeho vývoje převzalo konsorcium W3C (World Web Consortium) vládu nad specifikací. Kromě zmiňovaného konsorcia za tuto specifikaci nese zodpovědnost i organizace WHATWG5 a IETF (Internet Engineering Task Force). Organizace WHATWG byla založena v roce 2004 několika jednotlivci pracujícími pro společnosti vyvíjející prohlížeče, jako je Apple, Mozilla, Google, Opera a vyvíjí k HTML vlastní rozhraní API pro vývoj webových aplikací. IETF se skládá ze skupin odpovědných za Internetové protokoly, jako je http. HTML5 definuje nové rozhraní API WebSocket, které je postaveno na protokolu WebSocket, jež vyvíjí jedna z pracovních skupin IETF. Dále také přináší mnoho nových HTML značek pro sémantický popis struktury stránky, jako např. značky pro práci s multimédii, určení polohy, práci s grafickými objekty (Canvas), WebSocket a mnoho dalších. V HTML5 je možné vytvářet i offline webové aplikace. (Lubbers a kol., 2011) V jednotlivých příkazech tohoto jazyka, je popsáno pouze, co chceme získat, nikoliv jakým způsobem. 5 Zkratka reprezentuje Web Hypertext Application Technology Working Group 4


19

5 Analýza a návrh stávajícího IS V této kapitole bude provedena analýza a poté návrh stávajícího systému, což je odrazový můstek každého analytika při tvorbě jakéhokoliv informačního systému. Analýza by měla poskytnout přesné požadavky na systém.

5.1

Průzkum a struktura klubu

Organizační struktura klubu je postavena jako asi většina současných sportovních klubů - vedení klubu je reprezentováno předsedou klubu, jehož pomocnou rukou je místopředseda a výkonný výbor. Dalšími osobami zasahujícími do klubu jsou trenéři a nejpočetnější skupina – samotní hráči. Pozoruhodným jevem je fakt, že v tomto případě může jedna osoba zároveň představovat hráče, trenéra i být součástí vedení klubu. Vedení klubu má na starosti běžné úkony vedení, které zabezpečují bezproblémový chod klubu, avšak trenéři, kromě své typické činnosti – organizování a samotné provádění tréninků, dbají i o správu jednotlivých klubových družstev a jejich soupisek. Hráči absolvují tréninky, ty mohou být dvojího typu, první možnosti je trénink s přítomností trenéra a druhá pouze tzv. sparring, kdy hráči hrají mezi sebou. Termíny tréninků s trenérem bývají zpravidla fixně stanovené na začátku sezóny, zatímco trénink typu sparring lze domlouvat i nárazově pár dní předem. Za klasický trénink s trenérem každý hráč odvádí měsíční poplatky a jednou za rok je povinen zaplatit roční hráčské příspěvky. Samozřejmě veškeré tréninky, které hráči absolvují, mají svůj účel kromě celkového výkonového růstu každého hráče, ti nejlepší reprezentují klub v soutěžích družstev. Sportovní klub Tenis Tišnov (SKT Tišnov) vlastní v současné době pouze webovou prezentaci klubu postavenou na nejmenovaném redakčním systému, která zahrnuje základní informace o klubu a dění kolem něj.

5.2 Neformální specifikace Dle průzkumu a konzultace s předsedou klubu by se dalo říci, že klub potřebuje stále přístupný IS s funkcemi, které neposkytuje webová prezentace klubu. Daný systém by měl podporovat všechny důležité úkony každého uživatele, ale zároveň by jeho vývoj i provoz neměl být příliš finančně náročný.

5.3 Funkční požadavky Jednou z hlavních požadovaných funkcí informačního systému je bezpečný přístup každého autorizovaného uživatele s dělením na různá práva dle jeho role (hráč, trenér, vedení a správa klubu). Hráči by měli mít možnost editovat svoje osobní údaje, procházet statistiky a přehled o svých plánovaných utkáních za konkrétní družstvo.

20


Trenéři by měli mít právo editovat svoje osobní údaje, spravovat soupisky družstev a procházet informace o hráčích (statistiky). Jak hráči, tak trenéři by měli být schopni vytvářet rezervace na určité datum a čas na dvorcích klubu a procházet již vytvořené rezervace. Vedení a správa klubu (zahrnuje i administrátora) by pak zajišťovalo správu plateb a statistik a také by popřípadě mohlo kontrolovat správný vývoj družstev. Dále by mělo mít právo vytvářet uživatele a rovněž prohlížet vytvořené rezervace.

5.4 Hardwarové a softwarové požadavky V rámci hardwarových požadavků je nezbytné, aby bylo využito webového serveru pro splnění požadavku – stále přístupný IS. V současnosti patří mezi nejefektivnější metody provozu webového serveru jeho pronájem nebo zakoupení hostingových služeb u některé společnosti. V úvahu může přicházet také investice do výkonného počítače a využití ho k danému účelu, nicméně náklady jak na pořízení, tak provoz, popřípadě při výpadku a nutnosti zakoupení náhradních dílu, jsou mnohem vyšší než při využití první varianty. Z finančního hlediska i po softwarové stránce působí jako mnohem optimálnější varianta pronájmu či zakoupení hostingových služeb u některé vybraně společnosti. Tyto služby bývají k dispozici v podobě balíčků šitých na míru zákazníkům, další jejich výhodou je zpravidla také velmi kvalitní neustálá podpora. Varianta s investicí do výkonného počítače by vyžadovala pořízení a instalaci softwaru v podobě operačního systému, webového serveru a také databáze, vše jednoznačně finančně náročnější.

5.5 Shrnutí Jak již bylo zmiňováno, klub vlastní v současné době webové stránky spravované redakčním systémem, umístěné na hostingu nejmenované společnosti. Po pečlivém prověření se ukázalo, že daný hosting disponuje PHP ve verzích 5.3 a 5.4, databázovým systémem MySQL ve verzi 5.5 a také plnou podporou Frameworku Nette. Tyto služby se zdají, jako plně dostačující6 a případě potřeby lze využít také mnoho dalších užitečných služeb, jenž společnost v rámci hostingu nabízí.

5.6 Strukturovaná analýza Strukturovaná analýza byla provedena za pomocí CASE nástroje Power Designer 6 od firmy Sybase. Veškeré diagramy jsou navrženy tímto nástrojem.

6

Z čehož vyplívá, že není potřeba pronájmu dalšího hostingu.


5.6.1

21

Kontextový diagram

Kontextový diagram je speciálním případem Data Flow Diagramu, kdy je celý systém definován jedním hlavním procesem a jeho okolím v podobě několika terminátorů. Tyto externí entity musí nějakým způsobem komunikovat s hlavním procesem, to zajišťují datové toky, které jsou charakterizovány také šipkou značící směr toku dat (přijímá data nebo odesílá). Kontextový diagram by měl vystihovat jakousi základní představu systému. Při analýze byly stanoveny tři externí entity pracující se systémem. První z nich se nazývá Hrac klubu. Tvoří ji osoby, které jsou evidovány jako členové klubu a zároveň aktivně tenis hrají. Druhým terminátorem je Trenér, to mohou být kromě osob, které mají na starost pouze tréninky hráčů, i osoby plnící funkci jak trenéra, tak hráče. Poslední velmi důležitou externí entitou je Vedení a správa klubu. Do této skupiny patří osoby zabývající se správou klubu, jako jsou správce areálu dvorců, administrátor webových stránek, účetní klubu apod. Nicméně tuto entitu tvoří i osoby, jež představují vedení klubu, konkrétně se jedná o předsedu, místopředsedu a výkonný výbor klubu. I v tomto případě je možné, že např. předseda klubu, může být zároveň také hráčem a trenérem. Grafické znázornění kontextového diagramu je zobrazeno na obrázku 3.

22


Obr. 3

Kontextový diagram tenisového klubu SKT Tišnov

5.6.2

Systémový diagram

V systémovém diagramu, jenž znázorňuje obrázek 4, bylo nutné hlavní proces kontextového diagramu dále dekomponovat. V našem případě vznikly čtyři subprocesy – Sprava rezervaci, Sprava uzivatelu, Celkova sprava klubu a Sprava statistik. Výhodou dekompozice hlavního procesu na dílčí je kromě lepšího porozumění systému i určitá nezávislost7 jednotlivých subprocesů systému, toho lze využít např. při nezbytné údržbě nebo dočasném výpadku.

To neplatí pro subproces Správa uživatelů, který poskytuje bezpečný přístup autorizovaným uživatelům, bez něhož nelze IS používat. 7


Obr. 4

23

Systémový diagram tenisového klubu SKT Tišnov

Subproces Sprava rezervaci, jak už je z názvu patrné, má na starosti veškeré operace s rezervacemi na klubových dvorcích. Prostřednictvím tohoto procesu je hráč i trenér schopen prohlížet rozvrh na klubových dvorcích, tato operace je reprezentována datovým tokem „Info o casovem rozvrhu na dvorcich“. Jestliže má zájem o rezervaci na dvorcích, může zaslat tomuto procesu požadavek na rezervaci, což značí stejnojmenný datový tok. Obratem je danému hráči či trenérovi při úspěšném zarezervování zasláno potvrzeni o rezervaci. Data rezervací jsou uchovávána v datastoru Rezervace.

24


Další důležitý subproces se nazývá Sprava uzivatelu. Tento subproces pracuje se samotnými uživateli systému a s jejich osobními údaji. Například v situaci, kdy se chce uživatel přihlásit do systému, zadá svoje přihlašovací údaje, je subproces ošetří a porovná s přihlašovacími údaji uloženými v datastoru uživatelé. V případě shody dojde k úspěšnému přihlášení. Předchozí operace probíhají obdobně u všech uživatelů systému nezávisle na tom, zda se jedná o hráče, trenéra nebo patří do vedení klubu. Nicméně jsou tu i operace, jež může vykonávat pouze určitý typ uživatelů. Jedna z nejpodstatnějších se nazývá Vytvoření uživatele, kterou disponují osoby patřící do vedení a správy klubu Dílčí proces Celkova sprava klubu využívají téměř ve všech situacích uživatelé, kteří jsou zodpovědní za bezproblémový chod klubu, tedy patřící do externí entity Vedení a správa klubu. Jedinou výjimku tvoří datový tok, jehož prostřednictvím se hráčům dostává potvrzení o zaplacení jednotlivých plateb. V ostatních situacích se pomocí tohoto procesu dostává např. předsedovi klubu informací o průběhu plateb, časovém vytížení klubových dvorců (přehled rezervací) a detailní informace o jednotlivých rezervacích. Další dílčí proces, nazvaný Sprava druzstev, zprostředkovává veškeré činnosti spojené s jednotlivými družstvy klubu. Trenéři jsou tímto schopni editovat jejich soupisky a spolu s hráči mohou prohlížet informace o družstvech. Data družstev jsou uchovávány v datastoru Družstva. Posledním subprocesem je Sprava statistik. Pomocí tohoto subprocesu mají hráči k dispozici statistiky svých odehraných utkání (datový tok Statistiky hracu). Samotné statistiky zadává do systému uživatel pověřený vedením klubu (terminátor Vedení a správa klubu). Nejprve zadávané statistiky protečou datovým tokem Statistiky hracu k danému procesu a ten je poté uloží do datastoru Statistiky. 5.6.3

Entitně relační diagram

Tento diagram blíže charakterizuje strukturu dat, které je nutné uchovávat pro běh systému. Většinou je potřeba přidat některé další tabulky. Zvláště v případě, kdy mezi dvěma tabulkami vznikne vazba (relace) s aritou M:N. V praxi tento vztah nelze jednoduše popsat a ani relační databáze s ním neumí pracovat, tudíž je nezbytné mezi danými dvěma tabulkami vytvořit asociační tabulku, která složitou vazbu rozdělí na dvě jednodušší 1:N. Tento proces je často označován jako Dekompozice vazby M:N. V našem modelu je takovýchto situací více, jednou z těch méně tradičních je mezi tabulkami Uživatel a Role, kdy každý uživatel může plnit více rolí v systému a zároveň samozřejmě každou roli může zastávat více uživatelů. Toto je vyřešeno zavedením asociační tabulky Typ_role. Entitně relační diagram IS SKT Tišnov je znázorněn na následujícím obrázku 5.


Obr. 5

25

Entitně relační diagram tenisového klubu SKT Tišnov

Obecně je možné říci, že tabulka Uživatel je výchozí tabulkou celého systému. Každá osoba, která chce jakkoliv pracovat s IS, musí být v této tabulce evidována svým jménem, příjmením, datem narození a e-mailovou adresou, tyto atributy jsou typu varchar s definovanou maximální délkou. Kromě toho tabulka dále obsahuje svůj primární klíč8 id_uzivatel a cizí klíč9 id_prihl_udaje. Jednotlivé klíče bývají z pravidla celočíselného typu, v našem případě integer. Data rezervací uchovává tabulka Rezervace, jež obsahuje kromě primárního klíče cizí klíče id_uzivatel a id_dvorec také atributy datum, cas a delka trvani. S touto tabulkou pracují nejvíce uživatelé s rolí Hráč a Trenér. Každá rezervace je spojena s konkrétním dvorcem, to zajišťuje tabulka Dvorec. Další uživatelské informace, které systém uchovává, jsou statistiky hráčů. Je zřejmé, že tuto úlohu plní tabulka Statistiky. Ovšem jednotlivé statistiky mohou být filtrovány podle družstva, sezóny a typu utkání. Tato funkce je zabezpečena stejnojmennými dílčími tabulkami, jejichž cizí klíče jsou obsaženy v dané tabulce Statistiky. Samotná statistika se pak ukládá jako počet vyhraných utkání (atribut vyhr_utkani) a celkový počet utkání (atribut poc_utkani). S pomocí im-

Unikátní identifikátor (atribut) každého záznamu dané tabulky, musí být obsažen v každé tabulce (neplatí pro asociační tabulku) a je třeba, aby měl nenulovou hodnotu. 9 Jedná se v podstatě o odkaz na primární klíč jiné tabulky. 8

26


plementačních nástrojů jsou tyto informace poté zpracovány pro uživatele systému tak, aby disponovaly větší informační hodnotou. Každý uživatel IS může patřit do některého jednoho nebo více družstev. To vystihuje tabulka Družstva. V tomto případě můžete vidět další dekompozici vazby M:N poskytnutou asociační tabulkou Typ_uzivatel_druzstvo. Každé Družstvo klubu je charakterizováno více informacemi. Jednak svým názvem (atribut název_druzstvo10), ale i dalšími informacemi týkající se samotných utkání družstev. Družstvo se totiž účastní mistrovských utkání, tyto utkání se konají v určitém termínu, odehrávají se v určité soutěži a skupině a v případě, kdy je v klubu družstev dané věkové kategorie více, je tu ještě informace o třídě (A, B, C) daného družstva. Všechny tyto informace o utkání družstev musí být opět z důvodu existence vazby s aritou M:N mezi dílčími tabulkami a tabulkou Družstvo vyřešeny vytvořením asociační tabulky, tentokrát společné pro více M:N vazeb, s názvem Druzsvo_trida_soutez_skupina. V modelu můžeme vidět i netradiční vazbu 1:1 mezi tabulkou Uzivatel a tabulkou Prihlas_Udaje, samozřejmě by informace obsažené v těchto dvou tabulkách mohly být v jedné tabulce, nicméně hlavně z důvodu větší přehlednosti diagramu a poté databáze jsem zvolil variantu s vazbou 1:1. Poslední tabulka má název Platby, s pomocí ní má uživatel s rolí Hráč k dispozici přehled o svých uhrazených platbách a může do ní ukládat data plateb také uživatel patřící do vedení a správy klubu. Tabulka obsahuje svůj primární klíč id_platba, cizí klíč id_uzivatel a dále atributy castka typu smallint a uhrazeno typu bool.

Hodnota tohoto atributu zároveň určuje věkovou kategorii družstva, např. název družstva: Dospělí, Dorost, Starší žactvo apod. 10

Implementace

27

6 Implementace K implementaci IS SKT Tišnov bylo využito Frameworku Nette, který využívá objektové přístupu PHP a je stavěn na architektuře MVC (viz kapitola 4.2.1). V této části budou popsány jednotlivé funkce a možnosti, které systém nabízí jeho uživatelům. Objektový návrh modelu systému byl vhodně postaven na existenci tříd, které reprezentují jednotlivé hlavní entity pracující se stejnojmennými tabulkami v databázi. Všechny tyto třídy dědí základní funkce od abstraktního předka s názvem Stock.

6.1 Uživatelské rozhraní Nejprve je třeba zmínit skutečnost, že při jakémkoliv pokusu neautorizovaného uživatele navštívit domovskou stránku systému, je automaticky přesměrován na stránky obsahující pouze přihlašovací formulář s prvky pro zadání uživatelského jména a uživatelského hesla. Je tedy evidentní, že osobě, která není členem SKT Tišnov s určitou rolí, systém neposkytne absolutně žádné možnosti ani informace, jde o interní systém podniku, obecné informace o klubu poskytuje veřejnosti nezávisle webová prezentace klubu. Nyní už blíže k návrhu uživatelského rozhraní: Pro návrh uživatelského rozhraní jsem využil drátěného modelu, který znázorňuje základní rozvržení a je tvořen šesti částmi. Veškeré tyto části je možné vidět na obrázku 6.

28

Obr. 6

Implementace

Rozložení stránky pomocí drátěného modelu

Prvními dvěma podobnými částmi jsou záhlaví a zápatí. Záhlaví obsahuje název informačního systému a také logo klubu. Zápatí je tvořeno typickými daty, jako např. copyright a kontakty na administrátora. Další, lze říci důležitější část, je menu. Obsah této části se mírně liší, dle role právě přihlášeného uživatele, ale v zásadě se zde nachází tlačítko pro prohlížení plánu rezervací na dvorcích (s možností rezervaci vytvořit), dále tlačítko pro nahlížení do informací o družstvech a statistikách. V neposlední řadě menu obsahuje ve svém pravém úseku tlačítko se jménem přihlášeného uživatele, přes které lze nahlédnout a měnit svoje osobní údaje a poslední tlačítko s funkcí odhlášení. Odlišnost v menu nastává, jestliže je přihlášený uživatel součástí vedení a správy klubu, v tomto případě je menu doplněno o tlačítko Platby a Vytvořit uživatele a po kliknutí na tlačítko Rezervace, může uživatel pouze prohlížet přehled rezervací, nikoliv je vytvářet. V situaci, když by se jednalo o hráče, který je zároveň trenér a je také součásti vedení a správy klubu, bude mít tento uživatel k dispozici všechny zmiňované funkce reprezentována jednotlivými tlačítky menu.

Implementace

29

Následující dvě stejné části, co se do velikosti a vzhledového zpracování týče, ale s odlišnými obsahy jsou postranní panely. První z nich informuje o utkáních. O jakých utkáních to opět záleží na roli uživatele. Když jde o hráče, panel ho informuje o jeho maximálně šesti nejbližších nadcházejících utkáních. Neníli uživatel hráč klubu, ale pouze trenér nebo (a) patří do vedení klubu, panel ho informuje o nejbližších nadcházejících šesti utkáních daného11 družstva. Druhý panel hráče a trenéry klubu informuje o jejich vytvořených rezervacích na dvorcích klubu. Pro uživatele role Vedení a správa klubu je prozatím tento panel nevyužit, s tím že jeho přesná funkce bude později stanovena. Zbývající částí drátěného modelu nese již tradiční název Obsah, kde jsou zobrazeny výsledky akce systému. Například při akci kliknutí na tlačítko Rezervace je zde zobrazen přehled rezervací v tabulce s možností jejich vytvoření.

6.2 Autentizace uživatele Jedná se o zásadní funkci, kterou systém disponuje. V Nette je již obsažena třída Authenticator12, jejímž úkolem je právě autentizace. Základní verze třídy však nebyla zcela vyhovující, bylo tedy potřeba provést drobné úpravy. V šifrovací funkci jsem použil místo již nedůvěryhodného a složitého algoritmu MD5, chytrého algoritmu ve funkci crypt, kde je solení již součástí hashe. Tato metoda tedy dostane heslo jako parametr a vrátí jej v zahashované podobě. Avšak hlavní metodou této třídy je metoda authenticate. Zde bylo nutné pouze upravit vstupní data. Tato metoda nejprve dostane jako argument pole s přihlašovacími údaji uživatele, porovná, zda vůbec existuje řádek v databázi se zadaným uživatelským jménem, při neúspěchu vyhodí výjimku, v opačném případě teprve porovnává shodu zadaného hesla s heslem v databázi. Jestliže hesla také odpovídají, funkce vytvoří objekt typu Identity, s kterým se poté dále pracuje v dalších situacích. Bylo zde využito metod třídy userStock, nesmí být tedy opomenuta jejich následná implementace. Funkci authenticate a spolu s ní funkci pro zašifrování zadávaného hesla můžete vidět na obrázku 7. Dle architektury MVC jsme do této chvíle popisovaly pouze práci s modelem, v našem případě se třídou Authenticator. Zbývá ještě upravit předdefinovaný přihlašovací presenter a také view neboli šablonu. Presenter spojuje určitým způsobem model s jeho view. Nejprve tedy provede požadované operace modelu a poté požádá view o zobrazení jejich výsledku. V našem případě přihlašovací presenter v kostře Nette je sice také předpřipraven, avšak přihlašovací formulář je v něm celý v angličtině, což bylo vhodné upravit a doladit některé detaily. Za zmínku stojí přidání možnosti trvalého při-

Uživatelé zmiňované role nepatří do žádného družstva, tudíž si toho družstvo mohou vybrat z rozbalovacího menu, které se nachází v daném panelu. 12 Vzhledem k tomu, že je názvosloví ve Frameworku Nette včetně názvu souborů, tříd i metod kompletně v anglickém jazyce, bylo vhodné databázi i zdrojový kód systému psát také v anglickém jazyce, i když analýza a návrh našeho systému v angličtině není. 11

30

Implementace

hlášení, když uživatel toto políčko zaškrtne, vytvoří se sezení s expirační dobou 20 dní (MVC aplikace & presentery | Nette Framework, 2008-2013). Následně, když už jsme se postarali o aplikační logiku autentizace, je potřeba samotný formulář vykreslit pomocí zmiňované šablony. O šablony se v Nette stará šablonovací systém Latte. Tento systém opravdu značně zjednodušuje práci s daty. Pracuje se speciálními značkami tzv. makry, díky kterým, spolu s dalšími nástroji, lze PHP kód na několik desítek řádků zkrátit na minimum. Více o Latte se můžete dočíst na webových stránkách Šablony | Nette Framework (2008-2013)

Obr. 7

Funkce autentizace uživatele

6.3 Rezervace Spolu s autentizací uživatele je možnost uživatele vytvářet rezervace zcela nejdůležitějšími funkcemi systému. Implementace samotných rezervací se jevila jako mírně složitější než implementace ostatních funkcí systému a to z důvodu, že bylo nutné zajistit, aby data rezervací z databáze byly efektivním a uživatelsky přívětivým způsobem vyobrazeny v tabulce, která by samozřejmě reagovala na jakékoliv změny. Pro tuto situaci jsem se seznámil s některými volně dostupnými online rezervačními systémy jako je např. systém Reservio nebo systém MRBS. Nicméně jejich relativně složitá funkcionalita a možnosti nastavení mnoho detailů ke každé rezervaci mě dovedly k závěru, že optimální variantou

Implementace

31

řešení bude pokusit se vzít z daných systému to nejlepší a s použitím velmi jednoduché tabulky vytvořit rezervační systém šitý na míru pro potřeby SKT Tišnov. Jak lze vidět na obrázku 8, tabulka obsahuje v záhlaví sloupců dny v týdnu a také čísla jednotlivých dvorců klubu a záhlaví řádků zabírají časy rezervace. Toto zobrazení je výchozí, které uživatel role hráč a trenér uvidí při kliknutí na tlačítko Rezervace. Poté má možnost kliknutím na některou buňku tabulky reprezentující následující dny vytvořit svou vlastní rezervaci. Buněk tabulky samozřejmě může vybrat více, jelikož každá reprezentuje rezervaci daného dvorce jen na 30 minut. Poté pro dokončení rezervací je nutné kliknout na příhodné tlačítko Dokončení rezervace, jež už není součástí vloženého náhledu. Následně systém uživateli potvrdí vytvoření dané rezervace informační zprávou pod tabulkou. Vhodné je také zmínit možnost zobrazení detailů dané rezervace, kterou disponují osoby pověřené vedením klubu a naopak nemožnost rezervace vytvářet. Jednotlivé typy rezervací jsou charakterizovány různými barvami buněk tabulky: hráčské rezervace můžeme vidět červenou barvou, žlutá barva zastupuje rezervace vytvořené trenérem, jejichž základ většinou bývá napevno stanovený na celou sezónu, zelené jsou rezervace vytvořené právě přihlášeným uživatelem a poslední barva bledě modrá značí nemožnost vytvoření rezervace v daných časech a to z důvodu konání víkendových akcí v podobě mistrovských utkání družstev a turnajů jednotlivců.

32

Obr. 8

Implementace

Přehled rezervací dvorců při přihlášení uživatele s rolí pouze hráče

6.4 Družstva, statistiky a platby Jednou z dílčích funkcí systému je informování o družstvech klubu. K implementačnímu řešení bylo využito stejného technologického postupu jako při ostatních funkcích. Vytvořil jsem další třídu s názvem reservationStock, která opět dědí metody od svého předka Stock. Tato třída, jako jeden ze zástupců modelu v dané architektuře, implementuje datovou a funkční vrstvu, tedy metody potřebné pro manipulaci s družstvy. Její presenter13 provede určité potřebné operace s danými metodami a výsledky zase předá view (šabloně). Uživatel IS pak výsledky předchozí implementace může vidět jako např. přehled družstev na obrázku 9. Zde může dle potřeby změnit sezónu daných družstev a poté nahlédnout do podrobnějších informací o některém z nich. Tyto informace obsahují termíny utkání, soupisku, třídu a skupinu družstva. Jestliže je daný uživatel trenér, je mu k dispozici také tlačítko pro úpravu soupisky družstva.

Všechny presentery primárně také dědí některé základní metody od předka, který je oproti modelu již součástí kostry Frameworku, v Nette je to basePresenter. 13

Implementace

Obr. 9

33

Přehled družstev při přihlášení uživatele s rolí pouze hráče

Systém dále umožňuje hráčům i zobrazovat svoje statistiky14 a to po kliknutí na stejnojmenné tlačítko v menu uživatelského rozhraní, poté si hráč může pomocí formulářových prvků vyfiltrovat statistiku dle svých požadavků – nejprve si zvolí jaké sezóny se má statistika týkat, na jejím základě má potom na výběr pouze z družstev, do kterých se danou sezónu zapojoval (byl na jejich soupisce). Poslední filtr, který je nezávislý na předešlých, volí typ utkání, ale také nemusí byt specifikován, v tom případě se zobrazí statistiky pro oba typy utkání. Trenéři mají statistiky hráčů také k dispozici s tím, že před zobrazením daných filtrů musí navíc vybrat kterého hráče se daná statistika má týkat. Poslední funkce, jež je třeba zmínit, se týkají uživatelů patřících do vedení a správy klubu. Těm IS umožňuje spravovat platby15 a také vytvářet nové uživatele. Správa plateb je vyjádřena výpisem všech uživatelů, kde je každý řádek výpisu doplněn o formulářový prvek checkbox, jehož zaškrtnutím nabude atriStatistiky zadávají do systému osoby spadající pod vedení a správu klubu způsobem, kdy z výpisu všech hráčů vyberou toho, komu chtějí přidat statistiku a poté pomocí formulářových prvků, zadá s jakou sezónou, družstvem a typem utkání se statistika pojí a samotnou hodnotu statistiky. 15 Platby byly v systému navrženy pouze tak, že se týkají pouze plateb za minulý měsíc, starší platby by se museli řešit jiným způsobem. Vychází se tu z předpokladu, že hráč pravidelně hradí platby, tudíž jsou pro něho předmětný pouze stav platby za minulý měsíc, starší nikoliv. 14

34

Implementace

but zaplaceno tabulky Platba v databázi hodnoty true. Tento fakt pak může daný hráč vidět ve svých osobních údajích. Pokud je třeba vytvořit nového uživatele, pověřený uživatel této akce docílí kliknutím v menu na tlačítko Vytvořit uživatele, následně je vybízen systémem k vyplnění jména, příjmení, data narození a e-mailovou adresu uživatele, kterému chce vytvořit přístup do IS. Systém tato data uloží do databáze a s ošetřením řetězce příjmení vytvoří uživatelské jméno daného uživatele. Poté vygeneruje náhodný řetězec, který uloží jako heslo uživatele a tyto údaje odešle na zadanou e-mailovou adresu uživatele.

Závěr a přínosy systému

35

7 Závěr a přínosy systému Cílem této bakalářské práce bylo vytvořit informační systém tenisového klubu SKT Tišnov. Na základě pečlivě provedené analýzy informačních toků klubu pomocí CASE nástroje PowerDesigner a získání všech zásadních požadavků od předsedy a samotných hráčů byl vytvořen návrh systému. Analýza a návrh systému, se staly výchozím bodem pro zhotovení implementace systému. Funkcionalita systému byla kompletně popsána pomocí Data Flow Diagramu a strukturu ukládaných dat v databázi objasnil Entity Relationship Diagram. Co se týče implementace IS, považuji volbu využití Frameworku Nette za velmi podstatnou. Po seznámení se s důležitými rysy Frameworku a pochopení architektury MVC, mi tato technologie přinesla značné zvýhodnění v podobě jasného objektového návrhu a úspory času při zaměření se na konkrétní problematiku, o běžné situace se totiž Framework dokázal postarat sám, díky metodám a nástrojům, které má již zakomponované ve své kostře. V tomto momentě se systém připravuje ke vstupu do testovací fáze, pro kterou již bude nasazen na pronajatý hosting klubu vedle jeho běžící webové prezentace. Po určité době v této fázi a úspěšném provedení některých testů, popřípadě úpravě vzniklých nedostatků, bude systém nasazen do ostrého provozu a zpřístupněn všem osobám, kterým je určen. Nyní blíže k přínosům systému. Velkým přínosem vytvořeného systému je úspora času, která vzniká při využívání IS k rezervacím na dvorcích klubu. Jednotliví hráči a trenéři klubu již neztrácí každý týden cenné minuty domluvami pomocí textových zpráv nebo hovorů většinou prostřednictvím mobilních telefonů. S tímto souvisí další přinos, čímž je ušetření nákladů právě za zmiňovanou komunikaci přes mobilní telefony. Za přinos lze považovat také skutečnost lepší informovanosti každého uživatele přímo o termínech nadcházejících mistrovských utkání družstva, kterého je součástí a to přímo na hlavní straně systému (není nutné vyhledávat informace na jiných webových stránkách). Tímto opět vzniká úspora času a usnadnění povinností osobám, které měly tyto domluvy na starosti. V neposlední řadě je zde zamezeno vzniku jakýchkoliv nedopatření a nedorozumění právě při zmiňovaných domluvách. Popsanými přínosy vzniká další velmi důležitá výhoda systému a to je určitý uživatelský komfort, který je způsoben právě v podstatě bezstarostným vytvořením rezervace některého dvorce a dostatkem dostupných informací na jednom místě, které jsou pro každého člena klubu důležité.

36

Literatura

8 Literatura ALTHAMMER, E., PREE, W. Design and implementation of an MVC-based architecture for E-commerce applications. IN International Journal of Computers and Applications Volume 23, Issue 3, 2001, s. 173–185. BÖHMER, M. Zend Framework: programujeme webové aplikace v PHP. Vyd. 1. Brno: Computer Press, 2010, 416 s. ISBN 978-80-251-2965-4. CASTELLANO, M., PASTORE, N., ARCIERI, F., SUMMO, V., DE GRECIS, G.B. A modelview-controller architecture for knowledge discovery. IN Management Information Systems Volume 10, 2004, s. 383–392. ISSN 1470-6326. GUTMANS, A., BAKKEN S. S. a D. RETHANS. Mistrovství v PHP 5. Vyd. 1. Překlad Bogdan Kiszka. Brno: CP Books, 2005, 655 s. ISBN 80-251-0799-X. LUBBERS, P., B. ALBERS a F. SALIM. HTML5: programujeme moderní webové aplikace. Vyd. 1. Brno: Computer Press, 2011, 304 s. ISBN 978-80-2513539-6. MOLNÁR, Z. Podnikové informační systémy. Vyd. 2., přeprac. V Praze: České vysoké učení technické, 2009, 195 s. ISBN 978-80-01-04380-6. MRBS: Introduction [online]. [2012] [cit. 2013-05-15]. Dostupné z: http://mrbs.sourceforge.net/ MVC aplikace & presentery | Nette Framework. Rychlý a pohodlný vývoj webových aplikací v PHP | Nette Framework [online]. © 2008-2013 [cit. 201305-15]. Dostupné z: http://doc.nette.org/cs/presenters PHP: History of PHP - Manual. PHP: Hypertext Preprocessor [online]. © 2001-2013 [cit. 2013-04-15]. Dostupné z: http://www.php.net/manual/en/history.php.php Přihlašování & oprávnění uživatelů | Nette Framework. Rychlý a pohodlný vývoj webových aplikací v PHP | Nette Framework [online]. © 2008-2013 [cit. 2013-05-15]. Dostupné z: http://doc.nette.org/cs/security RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. V Tribun EU vyd. 1. Brno: Tribun EU, 2008, 139 s. ISBN 978-80-7399-599-7. Reservio - Online rezervační systém zdarma [online]. © 2012 [cit. 2013-05-15]. Dostupné z: http://www.reservio.com/cs/ SELFA, D.M., CARRILLO, M., DEL ROCÍO BOONE, MA. A database and web application based on MVC architecture. Proceedings of the 16th IEEE International Conference on Electronics, Communications and Computers, CONIELECOMP 2006. Volume 2006, 2006, Article number 1604744, s. 48–54. SYBASE PRODUCTS CZECH, S.R.O. [online]. © 2010 [cit. 2013-04-02]. Dostupné z: http://www.sybase.cz/index.php?option=com_content&view=article&id=3 &mid=2

Literatura

37

Šablony | Nette Framework. Rychlý a pohodlný vývoj webových aplikací v PHP | Nette Framework [online]. © 2008-2013 [cit. 2013-05-13]. Dostupné z: http://doc.nette.org/cs/templating ŠIMUNEK, M. SQL: Kompletní kapesní průvodce. 1. vyd. Praha: Grada, 1999, 247 s. ISBN 80-716-9692-7. WATANABE, K., IMAMURA, M., ASAMI, K., AMANUMA, T. A web application development Framework using code generation from MVC-Based UI model. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). Volume 5518 LNCS, Issue PART 2, 2009, Pages 404–411. 10th International WorkConference on Artificial Neural Networks, IWANN 2009.

Informační systém tenisového klubu SKT Tišnov

Recommend Documents