Realizace informačního systému florbalového klubu

Mendelova univerzita v Brně Provozně ekonomická fakulta

Realizace informačního systému florbalového klubu Diplomová práce

Vedoucí práce: Bc. Miroslav Hájek Ing. Michael Štencl, Ph.D. Brno 2013

Na tomto místě bych rád poděkoval vedoucímu práce panu Ing. Michaelovi Štenclovi, Ph.D. za rady a připomínky při vypracování práce.

2

Prohlašuji, že jsem diplomovou práci vypracoval samostatně za použití zdrojů, které uvádím v seznamu literatury.

V Brně dne 2. ledna 2013

………………..……………………….

3

Abstrakt Diplomová práce se zabývá problematikou realizace informačního systému florbalového klubu. Systém zajišťuje správu klubové administrativy a podporu procesů, které s ní souvisí. Uživateli systému jsou vedoucí pracovníci klubu a jednotlivých družstev. V práci jsou využity principy objektově orientovaného přístupu k vývoji aplikací. Na základě analýzy současného stavu a zjištěných požadavků na systém byl vytvořen jeho návrh. K modelování systému je využita notace jazyka UML 2.0. Následně byl systém realizován jako webová aplikace založená na technologiích společnosti Microsoft. Klíčová slova Informační systém, florbal, objektová analýza a návrh, návrhové vzory, UML, MVC

Abstract This thesis deals with the implementation of an information system for the floorball club. The system manages the club administration and support processes related to it. Users of the system are managers of the club and individual teams. In thesis are used the principles of object-oriented approach to application development. Based on analysis of current status and detects requests on system was created his design. For modeling of system is used UML 2.0 notation. Then the system was implemented as a web application based on Microsoft technologies. Key Words Information System, Floorball, Object-oriented Analysis and Design, Design Patterns, UML, ASP.NET MVC

4

Obsah 1.

2.

3.

4.

5.

Úvod a cíl práce ........................................................................................................... 8 1.1

Úvod ....................................................................................................................... 8

1.2

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

Teoretická východiska .............................................................................................. 10 2.1

Informační systém .............................................................................................. 10

2.2

Objektově orientovaný přístup ........................................................................ 10

2.3

Modelování a UML (Unifield Modeling Language) ..................................... 15

2.4

Návrhové vzory .................................................................................................. 17

Analýza současného stavu ....................................................................................... 20 3.1

Profil florbalového klubu .................................................................................. 20

3.2

Popis procesů v klubu ....................................................................................... 23

3.3

Současný informační systém ............................................................................ 25

3.4

Analýza alternativních řešení ........................................................................... 26

Analýza a návrh systému ......................................................................................... 27 4.1

Popis a využití systému..................................................................................... 27

4.2

Architektura systému ........................................................................................ 27

4.3

Analýza uživatelů systému............................................................................... 28

4.4

Požadavky na systém ........................................................................................ 28

4.5

Případy užití ....................................................................................................... 33

4.6

Diagram tříd ........................................................................................................ 41

4.7

Sekvenční diagram ............................................................................................. 46

4.8

Digram aktivit ..................................................................................................... 47

Implementace a nasazení.......................................................................................... 48 5.1

Adresářová struktura ........................................................................................ 50

5.2

Controllers ........................................................................................................... 51

5.3

Models.................................................................................................................. 52

5

5.4

Views .................................................................................................................... 52

5.5

Datová vrstva a databáze .................................................................................. 53

5.6

Řízení práv pro role ........................................................................................... 55

5.7

Nasazení .............................................................................................................. 56

6.

Výsledky a diskuze ................................................................................................... 57 6.1

Zhodnocení a přínosy ........................................................................................ 57

6.2

Ekonomické zhodnocení projektu ................................................................... 58

6.3

Možnosti rozšíření.............................................................................................. 59

6.4

Diskuze ................................................................................................................ 61

7.

Závěr ............................................................................................................................ 62

8.

Bibliografie.................................................................................................................. 63

9.

Seznam zkratek a pojmů........................................................................................... 65

10.

Přílohy ..................................................................................................................... 66

6

Seznam obrázků: Obrázek 1: Ukázka struktury třídy ..................................................................................... 12 Obrázek 2: Ukázka dědičnosti mezi třídami ........................................................................ 13 Obrázek 3: Ukázka asociace mezi třídami ............................................................................ 14 Obrázek 4: Ukázka agregace mezi třídami ........................................................................... 14 Obrázek 5: Ukázka kompozice mezi třídami ........................................................................ 14 Obrázek 6: Ukázka případu užití ......................................................................................... 16 Obrázek 7: Schéma MVC (5) ............................................................................................... 18 Obrázek 8: Schéma vzoru Repository (7) ............................................................................ 19 Obrázek 9: Organizační struktura vedení klubu ................................................................. 22 Obrázek 10: Organizační struktura vedení družstva .......................................................... 23 Obrázek 11: Schéma základní obrazovky ............................................................................. 33 Obrázek 12: Use Case - zobecnění aktérů ........................................................................... 34 Obrázek 13: Use Case - zobecnění funkcionalit CRUD ...................................................... 35 Obrázek 14: Případ užití pro subsystém „Adresář členů“ .................................................. 36 Obrázek 15: Případ užití pro subsystém „Cestovní příkazy“ ............................................. 38 Obrázek 16: Případ užití pro subsystém „Členské příspěvky“............................................ 39 Obrázek 17: Případ užití pro subsystém „Správa požadavků“ ........................................... 40 Obrázek 18: Případ užití pro subsystém „Kategorie a správa soupisek“ ............................ 41 Obrázek 19: Diagram tříd pro systém ................................................................................. 43 Obrázek 20: Sekvenční diagram editace soupisky ............................................................... 46 Obrázek 21: Diagram aktivit pro workflow schvalování požadavku ................................... 47 Obrázek 22: Sekvenční diagram pro Controller (8) ............................................................. 49 Obrázek 23: Ukázka obrazovky systému „Adresář členů" .................................................. 57 Obrázek 24: Ukázka obrazovky pro vytvoření cestovního příkazu ...................................... 58

7

1. Úvod a cíl práce 1.1 Úvod Florbal je nejprogresivněji se rozvíjející sport za několik posledních let. Velkou oblibu si našel zejména u mladé generace a stává se stále populárnějším sportem. Jeho hráčská základna se každoročně rozroste o několik tisíc členů. Z hlediska počtu členů je tento mladý sport druhý hned za fotbalem, který má v České republice dlouholetou tradici. S tímto masivním nárůstem členů souvisí i nároky správu a řízení florbalového klubu. Florbalový klub FK Slovan Jindřichův Hradec od založení v roce 2006 zaznamenal několikanásobné navýšení hráčské základny. V počátcích klubu nebyl potřebný žádný informační systém, ale stačilo klasické řešení tzv. tužka a papír. Postupně se přešlo na tabulkové editory, ale i ty přestaly časem dostačovat, protože obsahují určitá omezení. Mezi tato omezení patří

například

problematika

sdílení

dat,

jejich

synchronizace,

nároky

na bezprostřední dostupnost nebo omezení přístupu. Podpora informačních systémů pro sportovní oddíly je ze strany softwarových produktů jen minimální. Na trhu existuje několik řešení, ale každé má své omezení a zejména jejich cena hraje svou roli. Protože je florbal stále amatérský sport, nemůže si každý klub takovou investici dovolit. Pokud klub má finanční prostředky a chce investovat do informačního systému, je nejlepším řešením implementovat informační systém na zakázku než zakoupit takzvané „krabicové“ řešení. Individuální řešen na míru má výhodu v tom, že přesně pokrývá procesy v klubu a je navrženo podle jeho organizační struktury.

8

1.2 Cíl práce Cílem diplomové práce je navrhnout a implementovat informační systém pro potřeby florbalového klubu. Uživateli systému jsou vedoucí pracovníci klubu a členové realizačních týmů jednotlivých družstev. Tento systém by měl spravovat klubovou administrativu, zjednodušit a zefektivnit procesy, které se týkají chodu klubu a umožnit jeho lepší řízení. Systém zahrnuje evidenci členů, seznamy kontaktů, základní přehled finančních prostředků, komunikace mezi členy nebo správu požadavků od družstev. Vývoj systému se řídí principy objektově orientované přístupu a zahrnuje všechny jeho náležitosti od analýzy až po fyzickou implementaci. Výchozím bodem v této práci je provedení analýzy současného stavu a zjištění požadavků na systém a potřeb uživatelů. Na základě této analýzy bude navržen model systému pomocí notace UML 2.0, který bude dále sloužit jako předloha pro realizaci. Při vývoji je pro řízení životního cyklu použit inkrementální způsob vývoje. Systém bude implementován jako webová aplikace, která bude nasazena v rámci domény florbalové klubu. Aplikace je realizována využitím technologií a vývojových nástrojů od společnosti Microsoft. Součástí práce bude zhodnocení přínosů systému v praxi na základě minimálně měsíčního provozu a vyčíslení nákladů na projekt.

9

2. Teoretická východiska 2.1 Informační systém Informační systém (IS) je z hlediska veřejnosti chápán jako technický prostředek pro podporu určité činnosti. Tato činnost se liší podle oboru působnosti od komerčního sektoru, přes veřejný sektor až po neziskové organizace. Běžně se v životě setkáváme s nějakým informačním systémem. Může se jednat o vědomou nebo i nevědomou interakci. „Informační systém je systém metod, lidí a prostředků zabezpečujících informační procesy.“ (1) Každá z těchto složek tvoří specifickou součást systému a teprve jejich vzájemná interakce vytváří přidanou hodnotu pro uživatele IS. Správně implementovaný systém pomůže organizaci zvládnout problémy s řízením a provozem. Uživatelům poskytuje relevantní informace a výstupy v přehledné podobě. Je schopen zautomatizovat a zjednodušit procesy, které se dosud řešily neefektivně.

2.2 Objektově orientovaný přístup Spolu s vývojem informačních technologií rostou zároveň i požadavky na software a jeho vývoj. Programy jsou stále robustnější a složitější. Jejich udržovatelnost přesahuje hranice dosud tradičních přístupů (jako například strukturovaného). Právě kvůli nedostačujícím možnostem tradičního vývoje vznikl nový směr. Ten dokáže eliminovat nedostatky předchozích přístupů, ve kterých byl jen velmi těžko možné udržovat kód přehledný, a také časové požadavky na vývoj jsou mnohem nižší. V rámci objektové přístupu se můžeme setkat s těmito pojmy, které budou popsány dále v textu: o Objektově orientovaná analýza (OOA – Object-Oriented Analyse) Proces modelování systému z pohledu uživatelů. o Objektově orientovaný návrh (OOD – Object-Oriented Design)

10

Proces plánování spolupráce jednotlivých částí a objektů v programu – návrh systému. o Objektově orientované programování (OOP – Object-Oriented Programming) Fyzická implementace programu s využitím programovacího jazyka – implementace OOD. Objektově orientované programování představuje již tradiční prostředek při vytváření moderních programů nebo aplikací. Hlavním přínosem OOP je, oproti starším stylům programování, znovu-použitelnost kódu. Podle (2) objektově orientované programování zahrnuje následující výhody: -

Intuitivní přechod z business modelů k implementaci modelů.

-

Schopnost udržovat a implementovat změny v programech efektivněji a rychleji.

-

Možnost efektivněji vytvářet systémy v týmu, kdy každý odborník pracuje na části systému.

-

Možnost znovupoužití kódu v jiných programech a s minimálním úsilím implementovat produkty třetích stran.

-

Možnost tvořit mnohem více intuitivní uživatelská rozhraní

Objektově

orientovaný

přístup umožňuje

nahlížet

na software

jako

na skupinu objektů reálného světa. Tyto objekty pak reflektují prvky vyskytující se v konkrétním podnikovém prostředí. Objektem v informačním systému může být oddělení, uživatel nebo faktura. Objekty mezi sebou komunikují a jsou ve vzájemné interakci. Komunikace probíhá formou zpráv. Pohled na systém se blíží popisu reálných objektů, protože využívá přirozené myšlení. Charakteristiky objektově orientovaného přístupu: Objekty Na úrovni aplikace jsou všechny její části objekty i samotná aplikace je objektem. Objekt obsahuje atributy (vlastnosti), které můžou nabývat pouze hodnot z jejich definiční domény a operace. Každý objekt je charakterizován těmito vlastnostmi: 

Identita – určuje jedinečnou existenci objektu v čase a prostoru



Stav – stav objektu je definován hodnotami atributů v určitém okamžiku

11



Chování – popisuje akce a reakce objektu

Rozlišují se tři základní typy viditelnosti (zapouzdření) atributů a metod (operací): 1) Chráněné (Protected) – dostupné pouze objektům odvozených z dané třídy 2) Privátní (Private) – dostupné pouze v rámci objektu 3) Veřejné (Public) – atributů přístupné přímo, viditelné všem objektům Třída Skupiny objektů, které mají stejné, nebo podobné vlastnosti můžeme klasifikovat do konkrétních tříd. Třída představuje šablonu, podle které jsou pak objekty (instance) vytvářeny. „Třída definována jako deskriptor množiny objektů, které sdílejí stejné atributy, operace, metody, relace a chování“. (3) Zjednodušeně lze říci, že třída je šablona pro vytváření objektů (instancí). Objekty stejné třídy obsahují stejné atributy a stejné operace. Třídu z hlediska programování lze také chápat jako pohled na uložené entity, které představují objekty reálného světa, které potřeba uchovávat. Objekty jsou konkrétním výskytem třídy a nazýváme je instance.

Obrázek 1: Ukázka struktury třídy

Abstraktní třída Je speciálním typem třídy. Abstraktní třída nemůže vytvářet instance. Je zavedena jako důsledek dědičnosti a polymorfismu. Abstraktní nadtřída obsahuje společné prvky (atributy a operace) pro všechny své podtřídy. Podtřídy mohou obsahovat další své vlastní prvky.

12

Rozhraní Další speciální druh třídy. Stejně jako třída abstraktní nemůže vytvářet instance. Rozhraní nemůže obsahovat atributy, ale pouze konstanty a metody. Slouží především jako šablona pro definice metod, které mají obsahovat její potomci. Polymorfismus Umožňuje, aby dva objekty mohly odpovídat na jedno volání různě, každý svým způsobem. Polymorfismus je implementován pomocí metod. Výchozí metoda, která je umístěna v nadřazené třídě, je na úrovni svých potomků přepsána. Metody mají stejný název, ale mohou se lišit vstupními atributy. Dědičnost Dědičnost představuje možnost vytvářet hierarchii mezi třídami. Pro třídy se stejnými nebo podobnými vlastnosti a operacemi, lze vytvořit nadřazenou třídu, která zahrnuje jejich společné vlastnosti. Význam dědičnosti je v udržovatelnosti tříd, kdy při změně v definici nadřazené třídy jsou změny automaticky reflektovány i v podřízených třídách.

Obrázek 2: Ukázka dědičnosti mezi třídami

V praxi se nedoporučuje vícenásobné dědění (ideálně jednoúrovňové), kdy nadřazenou třídou je abstraktní třída nebo rozhraní. Asociace Asociace vyjadřuje vztah mezi instancemi tříd. Jedná se o spojení, které značí, že na úrovni instancí bude existovat vazba. Základní typ relace. Asociace indikuje, že třídy o sobě vzájemně vědí a je možná komunikace mezi nimi.

13

Obrázek 3: Ukázka asociace mezi třídami

Agregace Znamená, že objekt je složen z jiných objektů. Po zániku objektu, ale tyto objekty nezanikají a mohou v programu dále existovat.

Obrázek 4: Ukázka agregace mezi třídami

Kompozice Silnější druh vazby mezi instancemi. Jedná se o vztah celek/část neboli majitelství, které má několik striktních omezení. Instance třídy B nemůže existovat bez svého majitele A a nesmí být v systému, pokud již rodič neexistuje. V průběhu života existence instance nemůže změnit majitele a nemůže být vlastněna dvěma majiteli. (4)

Obrázek 5: Ukázka kompozice mezi třídami

Násobnost (Multiplicita) vazeb Odborná literatura hovoří o násobnosti takto: „Násobnost vazeb určuje počet objektů, které mohou být v libovolném okamžiku ve vztahu (v relaci) daného typu s jedním objektem protější třídy.“ (3) Přehled základních typů násobností mezi objekty: 0..1

žádný nebo jeden

1

přesně jeden

0..*

žádný nebo více

*

žádný nebo více

1..*

jeden nebo více

14

2.3 Modelování a UML (Unifield Modeling Language) S nástupem

objektově

orientované

přístupu

se

stalo

nedílnou

součástí

i modelování systému (analýza a návrh), které je výchozí fází. Smyslem modelování je navrhnout systém, co nejpřesněji podle požadavků zadavatele a ve spolupráci s ním také definovat jednotlivé procesy v systému. Modelování systémů má několik výhod pro všechny zainteresované strany. Především nedochází k neporozumění zadání (požadavků ze strany zadavatele). Uživatel má představu o tom, jak bude systém fungovat a programátor přesné zadání, jak to realizovat. Samozřejmě pro každou stranu jsou důležité různé modely systému. Některé poskytují pouze pohled na podnikový (business) model, který je klíčový pro zákazníka. A naopak třeba model struktury tříd v systému je klíčový pro vývojáře. Vytvoření kompletního modelu je základem pro úspěšnou realizaci. S čímž souvisí úspora prostředků (náklady a čas), kdy není nutné opravovat chyby vzniklé z nepochopení zadání. Modelování se dělí na tři úrovně: Konceptuální úroveň - Co? Co se bude modelovat, řeší objektově orientovaná analýza. Tato úroveň představuje první pohled na systém, nejsou zde řešeny podrobné technologické nebo implementační detaily. Jde o takzvané analytické modelování, kde jde míra detailu nula. Technologická úroveň - Jak? Jak bude provedeno převedení analýzy do podoby pro implementaci, řeší objektově orientovaný návrh. Odpovídá technologii, kde bude systém vyvíjen. V návrhu jsou již zahrnuty omezení daného prostředí. Fyzická úroveň - Čím? Kódování – nejnižší úroveň abstrakce, maximální detail implementace. UML (Unfield Model Language) UML je již tradiční a zavedený prostředek, který se v průběhu let stal standardem. Umožňuje systematické vytvoření modelu. Na model lze pak nahlížet z pohledu

15

logiky, fáze procesů, implementace, nasazení nebo případů užití systému. (3) Model obsahuje, jak textový popis systému, tak jeho grafické znázornění. Pro vizualizaci slouží digramy, které pokrývají jak statickou tak i dynamickou strukturu systému. UML vznikl jako pokus o sjednocení metodik, které se objevovaly při popisu software, kdy každé měla svojí syntaxi a vizualizaci. Neexistovala jednotná konvence a značení. Finální verze UML 2.0, která byla v práci využita, vznikla v roce 2005 a dnes je součástí většiny projektů. Diagramy notace UML popisují jak statickou, tak i dynamickou stránku systému. Zde je uveden výčet nejpoužívanějších modelů: Případ užití (Use Case) Případy užití popisují, jak budou uživatelé používat systém. Uživateli mohou být lidé nebo jiné systémy. V UML jsou uživatelé označováni jako Aktéři. Případ užití pomáhá popsat, jak uživatelé vidí systém a jaká je mezi nimi interakce. Je definována šíře a hranice systému.

Obrázek 6: Ukázka případu užití

V praxi se pro zjednodušení modelu používá zobecnění (generalizace) aktérů, kdy potomek hlavního aktéra přebírá všechny jeho případy užití a zároveň může přistupovat i k vlastním. Include je vztah mezi případy užití, kdy jeden případ užití začleňuje chování jiného případu užití.

16

Extend je vztah mezi případy užití, kdy jeden případ užití rozšiřuje své chování (svou funkci) pomocí jednoho nebo více fragmentů chování jiného případu užití. (3) Diagram tříd (Class diagram) Diagram znázorňuje objekty, jejich obsah a vztahy mezi nimi. Třídy zde představují datové struktury, které budou použity pro realizaci systému. Digram tříd popisuje statickou strukturu systému. Digram tříd může být využit ve všech úrovních modelování. Popis struktury tříd a vazeb byl uveden v kapitole výše. Sekvenční diagram (Sequence diagram) V UML se řadí k diagramům interakce, které zachycují posloupnost zasílání zpráv mezi objekty. Každý objekt má svojí vlastní čáru života, kde je zachycena časové vyjádření čekání na odpověď. Rozlišujeme dva druhy zpráv: synchronní (je vrácena opověď) a asynchronní. Diagram aktivit (Aktivity diagram) Diagramy aktivit jsou „objektově orientovanými vývojovými diagramy.“ (3) Představují vizuální tok vykonání procesu nebo operace. Často modelují business procesy a jejich workflow. Obsahují posloupnost kroků (aktivit), které nastanou od počátečního až ke koncového uzlu. Aktivity mohou běžet souběžně a je možné je vyhodnocovat na základě podmínek.

2.4 Návrhové vzory Při navrhování a tvorbě aplikaci se tvůrci dostávají do situací, kdy musí řešit složité situace. Protože se tyto problémy opakují, vznikly pro ty nejčastější z nich „šablony“ řešení. Jedná se o návrhové vzory, které pomáhají tyto problémy řešit. Návrhový vzor je šablony, které řeší vždy určitý typ problému. Jedná se o znovu použitelné šablony, které lze aplikovat ve více programech. Využití vzorů je ve fázi návrhu software, kde popisuji konstrukce tříd a vazby mezi nimi, aniž by bylo přímo určeno, o jakou třídu se musí jednat. Nelze je přímo použít do kódu. Návrhový vzor není přímo popis implementace.

17

Model-View-Controller (MVC)

Obrázek 7: Schéma MVC (5)

Tento vzor se stal v několika posledních letech velmi populární a jeho využití je především u webových aplikací. Smyslem vzoru je oddělit datovou vrstvu, aplikační logiku a prezentační vrstvu, tak aby byly na sobě co nejméně závislé. 

Model – nejnižší vrstva aplikace, která se stará se o správu dat, nad kterými aplikace pracuje. (6) Obsahuje třídy, které reprezentují strukturu dat a třídy, které se starají přístup k datům a manipulaci s nimi. Data jsou uložená převážně v relační databázi, ale může se jednat i o jiný zdroj.



View – zobrazení výsledků v uživatelském rozhraní (UI) pomocí dynamicky generovaného HTML. Uživatel s aplikací pracuje přes tyto zobrazené objekty.



Controller – zprostředkovává komunikaci mezi dvěma předchozími modely. Controller obsahuje třídy, které zajišťují komunikaci mezi uživatelem a aplikační logikou. Zprostředkovává komunikaci mezi View a Model.

Repository Základní myšlenka vzoru Repository je kompletně oddělit business modely od datové struktury. Data jsou uložená v datovém zdroji, nejčastěji to je SQL databáze a všechny operace směrem do zdroje jsou vykonávány přes tuto třídu. Jsou vráceny kolekce objektů nebo jeden objekt. Na úrovni těchto tříd je řešena i správa objektů – vytváření, mazání, aktualizace. Pro každý typ objektu je vhodné vytvořit příslušnou třídu Repository. V kombinaci se vzorem MVC je tato vrstva vrstvou abstraktní mezi databázovým obsahem a Controllorem.

18

Schéma vzoru Repository:

Obrázek 8: Schéma vzoru Repository (7)

Důvody použití: 

Centrální přístup k datovým zdrojům z různých míst.



Zlepšení udržovatelnosti kódu a oddělení business logiky a datové nebo servisní logice.



Do business logiky můžou být předávány entity různých datových zdrojů a typů.

19

3. Analýza současného stavu 3.1 Profil florbalového klubu Florbalový klub FK Slovan Jindřichův Hradec byl založen v roce 2006. Právní subjektivitu klubu zastřešuje sportovní organizace TJ Slovan Jindřichův Hradec o. s., která má sídlo v tomtéž městě. Hlavním úkolem klubu je zajištění provozování sportovní činnosti, kam patří tréninková činnost, soutěžní zápasy, organizace turnajů, přípravných soustředění a další související aktivity. V současné době florbalový klub má deset družstev v osmi věkových kategoriích. Od nejmladší kategorie elévů až po družstva dospělých. Celkově má přes 130 aktivních registrovaných členů. Všechny kategorie se účastní oficiálních soutěží a turnajů pod hlavičkou České florbalové unie (ČFbU)1. Za sezónu 2012/2013 sehrají družstva dohromady přes 200 soutěžních utkání a další v rámci přípravných turnajů a přátelských utkání. Právní subjektivita klubu a správa účetnictví jsou zastřešeny sportovní organizací TJ Slovan, ale všechny ostatní činnosti pro provozování a chod si klub zajišťuje sám. Mezi nejdůležitější patří správa hráčské základny, zajišťování finančních prostředků, administrativa směrem k ČFbU nebo rezervace hal a prostor pro tréninky a zápasy. Na chodu klubu se podílí několik členů vedení klubu, kdy každý má na starost určitou činnost. Je ovšem nezbytná jejich spolupráce a kooperace, tak by se všechny činnosti daly lépe plánovat. O zajištění sportovní činnosti se starají trenéři a jejich asistenti. Zároveň vystupují jako pojící článek mezi vedením a samotnými hráči. Proto musí být ve spojení s vedením, od kterého získávají informace. Finanční prostředky pro hospodaření si klub zajišťuje převážně z vlastních zdrojů. Největší část rozpočtu tvoří členské příspěvky, které si členové platí individuálně vždy za jednu sezónu. Výše příspěvku se liší podle kategorie a v závislosti na počtu členů, množství tréninkových jednotek a nákladů 1

Odkaz na oficiální stránky: http://www.cfbu.cz.

20

na dopravu na soutěžní zápasy. Další složku rozpočtu tvoří dary od sponzorů, dotace od sportovních asociací či města nebo vlastní marketingová činnost. To jsou však nestálé příjmy, a proto klub musí plánovat rozpočet hlavně na základě vlastních příjmů. Největší výdajovou složkou jsou pak náklady na pronájmy sportovišť, platby za start družstev v soutěžích a náklady na dopravu. Protože klub si sám nevede účetnictví, musí dokládat veškeré příjmy i výdaje. Organizační struktura vedení klubu Organizační struktura klubu je obdobná jako ve většině sportovních nebo dobrovolných organizací. Nejvyšší roli má v této hierarchii předseda a dále 4 členové vedení klubu. Nejvyšším orgánem klubu je valná hromada, kterou tvoří všichni členové klubu starší 18 let. Při hlasování o novém složení vedení, které probíhá každé dva roky, má každý jeden hlas. Vedení klubu se skládá celkem z pěti členů, kde každý člen má jeden platný hlas. Vedení klubu se schází pravidelně minimálně jedenkrát do měsíce a projednávaná aktuální problémy. Při hlasování rozhoduje většina, to znamená 3 z 5. Složení vedení klubu: Předseda – vystupuje za klub jako oficiální osoba, která má právo jednat. Zastupuje klub na jednání se sponzory, při jednání s florbalovou unií nebo na schůzích TJ Slovan. Předseda má podpisové právo za klub. Všechny smlouvy však ještě podléhají právnímu subjektu, který klub zastřešuje. Sekretář – stará se zejména o administrativní činnost v klubu. Zajišťuje veškerou komunikaci směrem k ČFbU, komunikaci se zástupci sportovních organizací a týmů, spravuje evidenci členů a stará se o přípravu smluv a podkladů. Pokladník – komunikuje s účetní jednotkou a staré se o veškeré činnosti související s finančními prostředky. Eviduje platby členských příspěvků, proplácí cestovní náhrady, odměny rozhodčím a další peněžní náhrady.

21

Člen vedení – ostatní členové nemají specifickou funkci, ale podílí se na administrativních činnostech, organizaci turnajů a zápasů, marketingu, správě informačních technologií a dalších činnostech. Schéma složení vedení klubu:

Obrázek 9: Organizační struktura vedení klubu

Organizační struktura vedení družstev V rámci florbalového klubu existuje 10 družstev v 8 věkových kategoriích. Každá kategorie je určena pouze pro hráče nebo hráčky v příslušném věkovém rozmezí. Složení vedení družstva: Trenér – je zodpovědný za vedení tréninkových jednotek, sportovní vedení hráčů a rozvoj jejich dovedností. Organizuje výjezdy na venkovní soutěžní zápasy. Osoba, která může vykonávat tuto funkci, musí být starší 18 let a musí být držitelem platné trenérské licence. V rámci soutěží jsou vyžadovány různé úrovně licencí. Asistent trenéra – spolu s hlavním trenérem se podílí na vedení tréninkových jednotek. Osoba nemusí být držitelem licence a muže být mladší 18 let, pokud nezastupuje hlavního trenéra. Vedoucí družstva – zajišťuje administrativní činnost kategorie. Mezi jeho úkoly patří správa soupisky, registrace nových členů, komunikace s vedením klubu. Tuto roli v praxi často vykonává hlavní trenér nebo asistent trenéra.

22

Obrázek 10: Organizační struktura vedení družstva

Každé družstvo má své vlastní vedoucí pracovníky. Každá kategorie musí mít hlavního trenéra. Pozice vedoucího družstva není vyžadována, může ji vykonávat zároveň hlavní trenér. Tyto dvě pozice jsou vyžadovány pro fungování kategorie v soutěžích ČFbU. U každé kategorie může působit i jeden nebo více asistentů trenéra. Takto složená jednotka má na starost svoji kategorii a je podřízena vedení klubu. S tím pak spolupracuje a komunikuje při vykonávání klubových činností. V případě požadavků např. na vybavení nebo prostory, musí žádat o jejich schválení vedení klubu. Dále pak s pokladníkem klubu vyřizují finanční záležitosti jako výběr členských příspěvků nebo proplácení cestovních náhrad.

3.2 Popis procesů v klubu Pro správný chod klubu je potřeba zajistit fungování základních procesů, které souvisí zejména s administrativou klubu a tokem finančních prostředků. Většina těchto procesů je v kompetenci jednotlivých členů vedení a neexistuje standardizovaná cesta, jak jich docílit. Během několika let, kdy klub funguje, se zažily určité postupy a stereotypy. Zajištění těchto procesů ale vyžaduje interakci několika uživatelů a je potřeba opakovaně vykonat určité aktivity, které vyžadují jak časovou, tak materiální investici. Protože klub pracuje v amatérských podmínkách a každý z organizace pracuje na základě dobrovolnosti ve svém volném čase, je vítána každá úspora času nebo prostředků.

23

Přehled hlavních procesů: A. Registrace členů a správa členské základny Registrace nového člena obnáší vyplnění přihlášek do TJ Slovan a do ČFbU. Po odeslání těchto přihlášek neeviduje klub informace o členovi, protože pak má sekretář oddílu možnost přístupu do sekce ČFbU, kde má k dispozici seznam členů. Tento seznam ovšem neposkytuje všechny údaje. Omezením je, že přístup k tomuto seznamu má jen sekretář oddílu a sdílení přístupu není možné. Kontakty na člena pak uchovává trenér nebo asistent kategorie, kde člen působí. Protože člen mezi kategoriemi přechází, musí se tyto informace pak znovu předávat. Dále klub musí evidovat aktuální počet členů, který vykazuje nadřazené jednotce, protože za každého člena odvádí roční poplatek. Fluktuace členů se pohybuje ročně v řádech desítek členů, proto je nezbytné udržovat aktuální stav. B. Soupisky Aby mohl hráč nastupovat do soutěžních zápasů organizovaných ČFbU, musí být přiřazen na soupisce kategorie. Hráči, kteří nastupují za dospělé kategorie, ještě musí uhradit registrační poplatek, jinak je není možné na soupisku přidat. Aktuální soupisku je možné získat ze systému ČFbU. Ze systému není možné získat historické soupisky. C. Cestovní příkazy Pro dopravu na zápasy používají členové své vlastní automobily nebo v případě dětí vykovávají dopravu jejich rodiče. V některých případech je použito prostředků veřejné dopravy jako autobus nebo vlak. To zejména v případě dopravy na celorepublikové turnaje mimo sezónu. Za vykonanou cestu má člen právo na proplacení cestovní náhrady na základě řádně vyplněného tiskopisu „Cestovní příkaz.“ D. Sledování výběrů členských příspěvků Donedávna probíhal výběr členských příspěvků hotovostní formou, takže pokladník musel osobně obcházet členy. Z časových důvodů pak byla často zainteresována osoba trenéra nebo vedoucího družstva jako prostředník. V posledním roce se přešlo na platbu bankovním převodem přímo na účet TJ

24

Slovan za pomoci specifických údajů každého člena. Platbu může pokladník v interakci s účetní jednotkou dohledat. Ovšem informace o platbě pak není dostupná trenérovi, který musí zajistit, že hrát zápasy a trénovat mohou pouze řádně platící členové. E. Tok dokumentů Výměna dokumentů mezi členy probíhá v rámci emailové komunikace. Toto řešení přináší klasické problémy při dohledávání dokumentů nebo se vyskytují různé verze. F. Požadavky Během sezóny se kumulují požadavky na vedení klubu. Především se jedná o zajištění materiálových potřeb pro tréninkové jednotky, žádosti na dopravu, náhradní nebo mimořádné jednotky pro trénování. Každý z těchto požadavků musí vedení vyhodnotit a vydat rozhodnutí. V současné době jsou požadavky směrovány emailovou adresu vedení klubu, odkud jsou přeposílány jednotlivým členům. Vyhodnocení pak probíhá na zasedání vedení nebo prostřednictvím emailové korespondence a žadatel, tak nemá žádnou zpětnou vazbu. Mezi největší problémy, se kterými se vedení klubu setkává, je nejednotné řešení a absence sdíleného informačního zdroje.

3.3 Současný informační systém V současné době klub nedisponuje žádným informačním systémem. Jednotlivé činnosti jsou zajišťovány individuálně různými prostředky. Nejčastěji je to formou dokumentů v tabulkových editorech a dále prostřednictvím emailové či jiné formy komunikace. Z toho vyplývají problémy, jako je správa těchto dokumentů, sdílení a synchronizace dat. Neexistuje žádný ucelený systém nebo forma správy dokumentů, který by pokrýval všechny aktivity klubu. Jediným technickým prostředkem, který má klub k dispozici, jsou webové stránky http://www.florbaljh.cz. Klub si platí tuto doménu a webhosting. Zde kromě oficiální prezentace klubu, existuje i sekce pro členy, která slouží jako oficiální sdělovací prostředek směrem ke členům (hráčům). Jedná se o diskuzi,

25

která je přístupná uživatelům v zabezpečené sekci chráněné heslem. Pro potřeby vedení žádné podobné řešení neexistuje.

3.4 Analýza alternativních řešení Jak nabídka nekomerčních produktů, tak i nabídka komerčních produktů pro sportovní kluby je téměř nulová. Na českém trhu jsem nalezl pouze jediný specializovaný systém, který částečně pokrýval požadované oblasti. Jedná se o aplikaci Sportvia.eu2. Jedná se o internetovou CRM aplikaci, která pokrývá tyto oblasti (vybrány oblasti pro potřeby klubu FK Slovan): 

Evidence členů



Finanční přehled



Řízení zaměstnanců a instruktorů



Komunikace mezi členy pomocí e-mail



Vytváření projektu



Reporting a statistiky Aplikace nepokrývá všechny požadované oblasti a má několik dalších

nevýhod. Mezi ty patří omezení velikosti diskového prostoru, které i v nejvyšší variantě zahrnuje pouze 150 MB (je možné rozšířit za příplatek). Mezi nevýhody patří cena za počet uživatelů, protože v tomto případě by byla potřeba nejvyšší licence. Mezi další alternativy patří využití CMS systému jako je například Drupal nebo Joomla, které poskytují relativně velkou volnost pro vlastní přizpůsobení, mají velký počet doplňků a modulů, které se dají dále parametrizovat. Výhodou je rozhodně jejich bezplatné pořízení, ale ani po vlastním přizpůsobení nebudou přesně splňovat zadané požadavky. Na trhu neexistuje komplexní produkt, který by přesně odpovídal požadavkům a pokrýval všechny oblasti. Samozřejmě existuje alternativní řešení využít pro každou oblast jiného produktu, ale tato varianta nepřináší uspokojivé řešení a zřejmě bude i finančně náročnější.

2

Dostupné na http://www.sportvia.eu/

26

4. Analýza a návrh systému 4.1 Popis a využití systému Jedná se o systém, který je určený pro správu administrativy a podporu řízení florbalového klubu. Zastřešuje řešení administrativy a souvisejících činností. Měl by uživatelům poskytovat nezbytné informace a výstupy, které jsou potřebné pro operativní rozhodování a řízení. Mezi základní funkcionality systému by měla patřit evidence členů a kontaktů, správa plateb, správa a vyhodnocování požadavků na vedení nebo informace o soupiskách a kategoriích, sdílení dokumentů. Dalším přínosem systému by mělo být zautomatizování procesů, které dosud uživatelé museli zabezpečovat manuálně. Od nového systému uživatelé očekávají, že budou mít nejdůležitější informace centralizovaně na jednom místě a budou k nim moci kdykoliv přistupovat. Odpadne tak problematika jejich dohledávání a využívání dalších systémů.

4.2 Architektura systému Protože se jedná o rozsáhlé řešení, které pokrývá správu několika agend, bude výsledný systém rozdělen na několik menších celků (subsystému), kde každý bude pokrývat specifickou oblast, která souvisí s řízením a správou florbalového klubu. Hlavním přínosem systému pro koncové uživatele by mělo být zjednodušení a zefektivnění běžných činností, které jsou nezbytné pro řízení florbalového klubu. Systém by měl pokrývat všechny oblasti, které bezprostředně souvisí s chodem sportovní organizace. Pro koncové uživatele to znamená, aby se co nejrychleji dostali k požadovaným informacím, měli kompletní přehled nad aktuální situací v klubu. Oproti aktuální situaci to znamená mít požadované informace na jednom místě, bez nutnosti je dohledávat.

27

Členění na subsystémy: 

Subsystém „Adresář členů“



Subsystém „Adresář osob“



Subsystém „Adresář týmů“



Subsystém „Cestovní příkazy“



Subsystém „Členské příspěvky“



Subsystém „Dokumenty“



Subsystém „Kategorie a soupisky“



Subsystém „Požadavky“

4.3 Analýza uživatelů systému Jak již bylo řečeno v úvodu práce, mezi uživatele systému budou patřit pouze členové vedení klubu a vedoucí pracovníci družstev. Systém není určený pro osoby z klubu, které nejsou zainteresovány na jeho vedení. V systému také není uvažováno o zpřístupnění pro veřejnost, protože uživatelem systému se může stát pouze člen klubu. V rámci systému budou funkce uživatelů převedeny na role a každá role budu mít určitou úlohu v systému. Vytvoření rolí je důležité pro pozdější specifikaci práv a funkcí v systému. Na základě přiřazení uživatele do role mu budou zpřístupněny odpovídající funkcionality. Mezi role budou dále přidána i role Hráč, která není v organizační struktuře vedení, ale bude sloužit pro identifikaci ostatních členů. Dále v systému existuje i role Administrátor, která není běžným uživatelem, ale slouží pro vytváření uživatelských účtů a správu přístupů. V rámci další analýzy nebude tato role uváděna.

4.4 Požadavky na systém Tato kapitola obsahuje seznam požadavků, které musí nový systém integrovat. Požadavky byly vytvořeny na základě analýzy současného stavu a jejich konkrétní definice vznikla na základě konzultací s budoucími přímými uživateli systému.

28

Protože výsledný systém by měl být komplexní produkt, který pokrývá několik oblastí, jsou jednotlivé požadavky řazeny podle těchto oblastí. Funkční požadavky A. Požadavky na systém 1) Autentizace a autorizace uživatelů -

Systém bude umožnovat přihlášení pouze určeným osobám – bude jim explicitně zřízen přístup.

-

Uživatel si bude moci změnit heslo, nikoliv přihlašovací jméno.

-

V systému budou rozlišena práva jednotlivých uživatelů podle rolí. Uživatel bude moci být v několika rolích zároveň. Každá role bude patřit ke konkrétní kategorii.

-

Systém nebude ukládat hesla v otevřené podobě. K ověření bude použita hašovací funkce a výsledný hash bude ověřen proti databázi.

2) Validace vstupů a kvalita dat -

Systém zajistí, aby uživatelské vstupy měly požadovaný formát nebo tvar.

-

Nebude možné ukládat záznamy bez vyplnění požadovaných polí.

3) Emailové notifikace -

Systém bude umět rozesílat emailové zprávy v rámci workflow jednotlivých procesů.

-

Zprávy budou zasílány vždy jen z jedné konkrétní adresy.

B. Požadavky na jednotlivé subsystémy 1) Subsystém „Adresář členů“ -

V subsystému bude možné vytvářet nové členy.

-

Bude možné měnit údaje člena a členy mazat. Systém neumožní smazat člena, pokud na něj jsou navázány jiné záznamy.

-

Vytváření a mazání záznamů muže vykonávat pouze určená role.

-

Lze si zobrazit seznam všech členů a existuje možnost vyhledávání a řazení záznamů.

29

-

U každého člena bude možné přejít na jeho detail, kde si uživatel bude moci prohlédnout všechny související informace i historické.

2) Subsystém „Adresář osob“ -

Lze si zobrazit seznam všech osob, je možné vyhledávat a řadit záznamy.

-

Vytvářet a editovat záznamy může každý uživatel.

3) Subsystém „Adresář týmů“ -

Lze si zobrazit seznam týmů a lze prohlížet jeho detail. V seznamu je informace, zda k danému týmu existuje kontaktní osoba.

4) Subsystém „Cestovní příkazy“ -

Systém poskytuje seznam všech cestovních příkazů. Záznamy je možné řadit. Tento seznam zahrnuje souhrnný řádek, kde je obsažena celková suma za viditelné záznamy.

-

Zobrazení záznamů je podmíněno rolí uživatele.

-

Systém umožňuje všem uživatelům vytvořit nový záznam. Vytvoření je formou formuláře. Uživatel zadává pouze proměnné, ostatní hodnoty jsou nabízeny formou seznamů.

-

Systém na základě zadaných hodnot dopočte celkovou částku za cestovní příkaz.

-

Po schválení/zamítnutí příkazu systém odešle notifikaci uživateli, který záznam vytvořil.

-

Schvalování má na starost konkrétní role.

5) Subsystém „Členské příspěvky“ -

Zobrazuje přehled členských příspěvků a jejich celkovou sumu. Také je možné záznamy řadit.

-

Zobrazení záznamů je podmíněno rolí uživatele.

-

Vytváření plateb a jejich potvrzení spravuje konkrétní role.

6) Subsystém „Dokumenty“ -

Subsystém poskytuje seznam dokumentů všem uživatelům. Je možné dokumenty řadit a vyhledávat v nich.

30

-

Uložení dokumentů je do databáze.

-

Nebude možné ukládat dokumenty větší než 3 MB a lze uložit pouze dokument, který je v podporovaných formátech. Jde o textové soubory, tabulkové, prezentace a dokumenty pro čtení.

7) Subsystém „Kategorie a soupisky“ -

Systém bude poskytovat přehled kategorií, seznam aktuálních hráčů na soupisce a jejich realizační tým. U kategorie si bude možné zobrazit i historické soupisky.

-

Měnit členy soupisek bude možné jen pro aktuální sezónu, nikoliv historické.

-

Na základě přiřazení člena na soupisku mu systém automaticky vygeneruje platbu členského příspěvku a odešle notifikaci.

-

Systém zajistí, aby nebylo možné přidat člena na více soupisek v jedné sezóně. Zároveň systém bude umožňovat přidat na soupisku vždy jen členy, kteří splňují věkový limit kategorie.

-

Bude možné přidávat kategorie a není možné smazat kategorii, ke které existují záznamy.

-

Správu soupisek bude spravovat konkrétní role.

8) Subsystém „Požadavky“ -

Uživatelé budou moci vytvářet požadavky na vedení klubu.

-

Po vytvoření požadavku bude odeslána notifikace všem členům vedení.

-

Každý člen vedení bude moci požadavek vyhodnotit a systém bude sledovat celkové hodnocení požadavku.

-

Uživatel může sledovat aktuální stav požadavku. Bude vždy upozorněn po individuálním hodnocení i po celkovém.

9) Zasílání upozornění -

Systém bude schopen pro zasílat emailová upozornění, které budou souviset s workflow procesů.

31

Nefunkční požadavky a) Webová aplikace Systém musí být navržen tak, aby mohl být realizován a implementován jako webová aplikace. Musí být dostupný všem uživatelům z prostředí internetu přes webový prohlížeč. Systém musí být nezávislý na operačním systému uživatelova klientského počítače. Uživatel si nemusí instalovat žádný další software. Systém musí být dostupný odkudkoliv, a to 24 hodin denně. b) Umístění v rámci domény webových stránek Protože klub má zakoupenou doménu a pronajatý prostor, kde v současnosti běží jejich internetové stránky, je nutné, aby systém fungoval v tomto prostředí. Provozní

systém

bude

dostupný

z adresy

domény

třetího

řádu

– http://isfk.florbaljh.cz. Aplikace bude umístěna ve stejném FTP prostoru a bude použita i stejná databáze. Tabulky týkající se informačního systému budou označeny prefixem “isfk_“. c) Použité technologie Klub disponuje webhostingem od společnosti Web4U s.r.o. Konkrétně se jedná o tarif ASP.NET Optimal.3 Systém musí být realizován tak, aby fungoval v tomto prostředí, proto musí být použita technologie .NET. d) Jednotné uživatelské rozhraní Uživatelské rozhraní informačního systému musí mít jednotný vzhled. Rozhraní bude tvořeno jednou hlavní stránkou. Tato stránka definuje základní rozložení objektů. Na stránce se budou nacházet tři hlavní části. V záhlaví stránky bude informace o přihlášeném uživateli a operace pro přihlašování/odhlašování. V levé části bude statické menu, které nemění svůj obsah a obsahuje odkazy na jednotlivé části systému. V centrální části obrazovky bude umístěna část pro zobrazování informací. Tato část se dynamicky obnovuje v závislosti na aktivitách uživatele.

Podrobnosti o webhostingu ASP.NET Optimal (http://www.web4u.cz/cs/webhosting/asp-netwebhosting) 3

32

Obrázek 11: Schéma základní obrazovky

e) Ukládání dat a zálohování Všechna data budou ukládána do relační databáze, kterou poskytuje poskytovatel webhostingu. Důvodem je zjednodušení zálohování a zabezpečení dat. Bude zajištěno pravidelné zálohování dat. To je zajištěno ze strany poskytovatele, kdy je jedenkrát týdně prováděna záloha databáze v konkrétním časovém intervalu, který neměl omezit provoz systému. Záloha aplikace bude provedena při nasazení systému a bude umístěna na zálohovém médiu. Vytvoření zálohy bude provedeno vždy v případě nasazení nové verze aplikace.

4.5 Případy užití Případy užití představují využití systému uživatelem. V rámci systému je nutné namodelovat všechny možné případy užití a to pro každou roli. Protože systém je složen z několika subsystémů, není možné tyto případy zachytit v jednom diagramu a budou namodelovány jednotlivě. Zobecnění aktérů V analýze uživatelů byly definovány role uživatelů, kteří budou systém používat. Při modelování případů užití se tito uživatelé označují jako aktéři. Pro zjednodušení a přehlednost diagramů byla využito zobecnění aktérů (generalizace aktérů). Zobecnění má dvě úrovně.

33

Následující obrázek vyjadřuje hierarchii zobecnění:

Obrázek 12: Use Case - zobecnění aktérů

V tomto zobecnění aktér Uživatel představuje uživatele systému bez rozlišení role, protože není potřeba pracovat s právy dané role. U případů užití, kde je specifická funkce systému, která je poskytována jen pověřeným osobám, bude konkretizován aktér podle role. V první úrovni zobecnění pracuje se dvěma novými aktéry, kteří nevzešli z analýzy uživatelů. Nejedná se o skutečné role, ale jsou využity pro modelování systému. Prvním takovým je aktérem Člen vedení klubu, ten zastupuje role Předseda, Sekretář, Pokladník a Člen vedení. Druhým aktérem je Člen vedení družstva, ten zastupuje role Trenér, Asistent trenéra a Vedoucí družstva. Druhá úroveň zobecnění již představuje skutečné uživatele systému. Zobecnění případů užití pro správu objektů Další

způsobem

zpřehlednění

diagramů

je

zobecnění

případů

užití

pro funkcionalitu správy objektů v subsystémech. Správou objektů je myšlena funkcionalita vytváření objektů (Create), čtení (Read/Retrieve), aktualizace (Update) a mazání (Delete). Běžně jsou tyto funkce sdružovány do tzv. CRUD funkcionality. V diagramech je použit vzor CRUD4 pro modelování případu užití. (8) Na obrázku č. 8 jsou vidět dva vzájemně ekvivalentní případy užití.

4

V cizojazyčné literatuře je označován jako CRUD Pattern.

34

Obrázek 13: Use Case - zobecnění funkcionalit CRUD

Následující případy užití popisují hlavní subsystémy informačního systému. Pro použití systému je nezbytné, aby byl uživatel přihlášen. Je to podmínka využití všech funkcionalit systému. Aktér Uživatel je vždy přihlášen do systému. Aktivita přihlášení k systému už není v jednotlivých případech uváděna. A. Případ užití pro subsystém „Adresář členů“ Aktér Uživatel zastupuje všechny role uživatelů systému. Uživateli se po vstupu do subsystému zobrazí seznam všech členů a může záznamy procházet. Uživatel má možnost si seznam seřadit podle kritérií jako je jméno, příjmení, datum narození, datum registrace nebo stav člena (aktivní/neaktivní). Řadit je možné sestupně i vzestupně. Předpokládá se, že seznam bude rozsáhlý, a proto bude k dispozici i systémová funkce vyhledávání. Uživatel zadá do pole pro vyhledávání celé jméno nebo příjmení. Může zadat i jejich část. Poté je mu zobrazen seznam se záznamy, které vyhovují vyhledávanému řetězci. Po nalezení požadovaného člena si může Uživatel zobrazit jeho detail. Na detailu jsou k dispozici podrobné informace o konkrétním záznamu. Jako rozšiřující funkcionalita je na detailu možné zobrazit si doplňující informace o členovi a jeho působnosti v systému. Na kartě člena si může Uživatel nechat vypsat informace o platbách, požadavcích nebo historii. Tento případ užití nastává v situaci, kdy Uživatel potřebuje zjistit informace o členovi. Například potřebuje dohledat telefonní číslo, aby mohl člena kontaktovat. Další situací je, když Člen vedení družstva potřebuje dohledat platby členských příspěvků nebo zkontrolovat cestovní příkazy za zápasy.

35

Druhý aktér v tomto případu užití je Sekretář. Tento aktér má stejné možnosti jako aktér Uživatel. Kromě toho má i své specifické případy užití. Sekretář může vytvářet nové členy, jak bylo specifikováno v požadavcích na systém. Sekretář po vstupu do subsystému má možnost vytvořit nového člena. V takovém případě se otevře formulář a vyplní jednotlivá pole podle papírové přihlášky člena. Dále může spravovat objekty typu člen, což zahrnuje editaci záznamů nebo jejich smazání. U členů, kteří již v klubu nepůsobí, se preferuje varianta nastavení vlastnosti člena jako neaktivní. Pro ostatní funkce správy objektů, musí Sekretář nejprve vykonat vyhledání záznamu, který chce modifikovat.

Obrázek 14: Případ užití pro subsystém „Adresář členů“

Stejným způsobem jsou využívány i další dva subsystémy „Adresář osob“ a „Adresář týmů“. U obou platí možnost zobrazování seznamů nebo vyhledání záznamu. Funkcionalita správy objektů je přístupná všem uživatelům. Jediný rozdíl je, že v seznamu externích osob není možnost zobrazení souvisejících záznamů, protože se nejedná o uživatele systému. Detail týmu při otevření zobrazí Uživateli přehled kontaktů, kteří jsou přiřazeni k tomuto týmu. Záznamy fungují jako odkazy, takže lze přejít ihned na detail údajů bez rozlišení aktéra. Všichni uživatelé mohou vidět všechny záznamy a stejně tak je i vytvářet, editovat nebo mazat.

36

B. Use Case pro subsystém „Cestovní příkazy“ Případ užití obsahuje tři typy aktéru. Prvním je Uživatel, který při využití subsystému si může zobrazit seznam zadaných cestovních příkazů. Zobrazení poskytuje vždy záznamy týkající se konkrétního Uživatele a záznamy pro jeho kategorii (kategorie) pokud je tento aktér současně Člen vedení družstva. Uživatel může zakládat nové nebo prohlížet detaily existujících. Další aktér Člen vedení klubu využívá subsystém jako první aktér, ale při zobrazení cestovních příkazu vidí všechny záznamy. Poslední aktér v tomto případu užití je Pokladník. Ten zahrnuje všechny předchozí případy užití pro všechny aktéry. Dále má možnosti využití systému pro vyhodnocení cestovního příkazu. Vyhodnocení předchází ověření informací jako je kontrola dat, vzdálenosti nebo účelu cesty. Tyto činnosti systém přímo nepodporuje. Takže například ověření vzdálenosti je provedeno přes měření trasy pomocí portálu s mapami. Účel cesty je buď všeobecně známý, nebo jej lze ověřit u jiného člena vedení.

37

Obrázek 15: Případ užití pro subsystém „Cestovní příkazy“

C. Use Case pro subsystém „Členské příspěvky“ Aktér Uživatel nemá možnost zadávat nové platby členských příspěvků, protože platba se bude generovat na základě přiřazení hráče na soupisku. Uživatel si může pouze zobrazit svoje členské příspěvky a platby v rámci kategorie. U tohoto aktéra je nutné rozlišit jeho roli v klubu. Ačkoliv uživatelé v této roli mají stejné možnosti, zobrazení dat je ovšem různé. Pokud se uživatel nachází v roli, která patří mezi vedoucí pracovníky klubu (aktér Člen vedení klubu), zobrazují se mu data za celý klub, tj. za všechny kategorie a členy. Uživatel, který je v roli vedoucího pracovníka družstva, má práva na data pouze pro svoji kategorii, respektive kategorie, pokud působí u více. Aktér Pokladník zadává platbu členských příspěvků. Kromě platby v hotovosti mohou členové využít i bankovní převod. Tento způsob platby je výhodný pro členy, ale pokladník poté musí platbu dohledat u organizace, která

38

zajišťuje právní subjektivitu. Klub si z důvodu správy účetnictví nemůže založit vlastní

bankoví

účet,

a

tak

synchronizace

plateb

je

zprostředkována

přes pokladníka. Po ověření platby zanese tento údaj do systému – provede potvrzení platby.

Obrázek 16: Případ užití pro subsystém „Členské příspěvky“

D. Use Case pro subsystém „Požadavky“ Aktér Uživatel může vytvořit požadavek na vedení klubu a dále sledovat, zda byl vyhodnocen či nikoliv. Na základě toho případu užití, kdy je vytvořen nový požadavek, je členům vedení odeslán e-mail o jeho vytvoření. Uživatel opět vidí jen požadavky svoje a za kategorii. Aktér Člen vedení

provádí vyhodnocení požadavků.

Zobrazí si detail

požadavku a provede vyhodnocení. Vyhodnocení obsahuje jednu z variant - schválil nebo neschválil a je možné připojit nepovinný komentář. Na základě těchto vyhodnocení je určen stav požadavku. Pro jeho schválení je vyžadováno

39

kladné vyhodnocení od tří z pěti členů vedení. Po každém vyhodnocení je autorovi odeslán e-mail s informací stavu.

Obrázek 17: Případ užití pro subsystém „Správa požadavků“

E. Use Case pro subsystém „Kategorie a soupisky“ Případ užití popisuje využití systému aktérem Sekretář, který používá funkce pro správu kategorií a soupisek. Tento uživatel může vytvářet nové kategorie nebo k existujícím kategoriím přiřazovat hráče. Úprava soupisek je dostupná jen pro aktuální sezónu. Případ užití Přidat hráče na soupisku zastřešuje i přidání členů vedení družstva. Aktér Uživatel pak má možnost si zobrazit seznam kategorií a prohlížet jejich soupisky.

40

Obrázek 18: Případ užití pro subsystém „Kategorie a správa soupisek“

4.6 Diagram tříd Z analýzy požadavků a z jednotlivých případů užití byl navržen diagram tříd. Třídy jsou navrženy podle objektů zachycených ve fázi analýzy požadavků a modelů případů užití. Digram obsahuje návrhové třídy, u kterých jsou již rozlišeny datové typy jednotlivých atributů a také provedena identifikace vazeb a jejich zpřesnění. Využití tohoto návrhu bude klíčové ve fázi implementace systému, kde budou jednotlivé třídy implementovány do vybraného prostředí. Systém je složen z několika nezávislých subsystémů, ale některé třídy jsou sdílené a vyskytují se ve více částech systému. Proto byl zachycen celkový pohled na systém, aby byla dobře pochopitelná jejich vzájemná závislost. V návrhu jsou implementovány dvě abstraktní třídy. První je třída Osoba, od které jsou odvozeny třídy Člen a Externí osoba. Třída Osoba obsahuje atributy společné pro dva své potomky. Tato třída má vazby na třídy Telefon, Email a Adresa, kde se jedná o vazbu typu kompozice. Neboli instance těchto tří tříd jsou spjaté s instancemi tříd Člen a Externí osoba, kde pokud zanikne jejich instance, zaniknou i závislé instance. Druhou abstraktní třídou je třída Platba, která má

41

potomky Členský příspěvek a Cestovní příkaz. V případě Členského příspěvku je atribut Status informací o jeho zaplacení členem a v případě Cestovního příkazu jde o informaci, zda ho pokladník schválil a proplatí ho. Fyzické uložení tříd, které jsou potomky abstraktní třídy, jsou vždy uložené do jedné tabulky, která obsahuje všechny atributy ze všech tříd a je pojmenovaná po abstraktní třídě. Tabulka pak obsahuje sloupec Discriminator, který rozlišuje, který záznam odpovídá jaké třídě. U vazeb mezi třídami, kde je definována směrovost, se jedná o vztah Odkaz do seznamu (Číselníková vazba). (4) Jde opět o vztah až na úrovni instancí daných tříd. Instance, která se odkazuje do seznamu, může pro daný atribut nabývat pouze hodnot vyskytujících se v seznamu.

42

Obrázek 19: Diagram tříd pro systém

Třída Člen Tato třída je potomkem abstraktní třídy Osoba a dědí od ní atributy. Problematika vazeb kompozice pro rodičovskou třídu byla již zmíněna výše, ale nebyla řešena multiplicita vazeb. Z návrhu vyplývá, že třída muže mít jednu nebo žádnou instanci Adresy, Telefonu a Emailu. Při realizace bude zajištěno, že tato vazba bude pro Člena jedna ku jedné. Protože podle požadavků tyto hodnoty musí být vyplněny. Nulová hodnota jde zde zavedena z důvodu existence třídy Externí osoba, která tyto hodnoty mít nemusí.

43

Třída Uživatelský účet Tato třída představuje uživatelské účty, pod kterými se uživatel hlásí do systému. Vytvoření instance této třídy je podmíněno existencí instance člena. Člen může mít žádný nebo právě jeden uživatelský účet. Třída Požadavek Třída obsahuje vazby na třídu Člen, kdy požadavek je vždy vytvořen jedním členem a ten může vytvořit libovolné množství požadavků. Dále je zde vazba na třídu Hodnocení, kde se jedná vazbu 1 : 0..5. Každý požadavek může mít maximálně 5 hodnocení, což odpovídá počtu členů vedení klubu. Vazba je typu kompozice, kdy hodnocení může vzniknout po vytvoření požadavku. Požadavek je vždy vytvořen pro 1 kategorii. Třída Historie členů Důležitou třídou v systému je třída Historie členů, kde člen musí mít minimálně jeden záznam (jeho instanci), která obsahuje roli člena při jeho vytvoření. Historie člena kromě člena a role obsahuje i sezónu a kategorii. Při registraci člena v systému se tyto hodnoty vyplňují defaultními hodnotami, protože nemohou být prázdné. Tím vzniká role uživatele v klubu. Člen může mít několik rolí. Při ukončení působnosti člena v roli nebude instance této třídy smazána, ale atribut Do bude nastaven na konkrétní datum a to znamená, že již není aktivní v dané roli. Přiřazením člena na soupisku se vytvoří záznam, kde bude vyplněna Kategorie a Sezóna podle vybraných hodnot. Třída Cestovní příkaz Cestovní příkaz obsahuje údaje nezbytné pro vyhodnocení cesty. Kromě časových informací a informací o trase, jsou zde informace nezbytné pro výpočet finální částky. Atribut Celkové náklady není fyzicky ukládán, ale vždy se dopočte při práci s objektem. Jeho výpočet je závislý na Typu dopravy. Sazba za Km je stanovena dle interních předpisů klubu, je tedy přednastavena jako konstanta.

44

Třída Členský příspěvek Obsahuje

atribut

Výše

příspěvku,

který

znamená

požadovanou

částku

pro kategorii v sezóně. Ostatní atributy jsou zděděné z rodičovské třídy. Třída Platba Třída má vazbu na třídu Člen. U Cestovního příkazu označuje, kdo cestu vykonal, ačkoliv Cestovní příkaz mohl zadat někdo jiný. U Členského příspěvku vazba na člena znamená, pro koho byla vygenerována. Při implementaci je přidána ještě jedna vazba na třídu Člen, která slouží pro informaci, kdo Platbu vytvořil. Ve fázi analýzy a návrh jsou názvy jednotlivých tříd uváděny v českých názvech, ale při realizaci budou převedeny do angličtiny.

45

4.7 Sekvenční diagram Sekvenční diagram popisuje sekvence systému, které se odehrají při jeho využití. Následující sekvenční diagram popisuje aktivitu, kdy je přidáván nový hráč nebo vedoucí družstva na soupisku a ukazuje kroky, které se v interakci objektů odehrávají.

Obrázek 20: Sekvenční diagram editace soupisky

Sekretář si zobrazí soupisku pro kategorii v určité sezóně, zobrazí se mu přehled členů, kteří splňují požadavky zařazení na soupisku - splňují věková kritéria a jsou vedeni jako aktivní členové. V seznamu provede výběr, může označit nové členy nebo odstranit stávající. V případě trenéra a vedoucího družstva lze vybrat jen jeden záznam. Při potvrzení výběru jsou hodnoty odeslány pro uložení do historie členů. Nové záznamy jsou přidány a u stávajících se nastaví datum pro ukončení aktivity. Dále se objekty, kde se jedná o roli Hráč, porovnávají na seznam plateb. Pokud platba neexistuje, je vygenerována a je členovi odeslána notifikace.

46

4.8 Digram aktivit Diagram aktivit pro proces schvalování požadavku, který popisuje jednotlivé aktivity od založení až po konečné vyhodnocení. Tento proces nezahrnuje aktivity, které na sebe přímo navazují v jeden časový úsek, ale proces celkového workflow.

Obrázek 21: Diagram aktivit pro workflow schvalování požadavku

Uživatel založí nový požadavek. Po jeho založení už nemá možnost jej měnit. Všichni členové aktuálního vedení obdrží notifikaci o vytvoření požadavku. Pak je vyžadována aktivita Člena vedení, který provede svoje vyhodnocení požadavku. Následuje aktivita odeslání informace hodnocení autorovi požadavku a kontrola, zda už byl požadavek hodnocen ostatními členy vedení. Pokud počet hodnocení se stejným rozhodnutím (schváleno nebo zamítnuto) je větší nebo rovno 3, znamená to, že požadavek byl vyhodnocen a autor obdrží informaci o finálním vyhodnocení.

47

5. Implementace a nasazení Podle požadavků na systém musí být systém realizovaný na platformě .NET. Na této platformě jsou možné dva přístupy programování. Prvním je přístupem je ASP.NET WebForms. Tento přístup vychází z vývoje desktopových aplikací pro Windows. Webové stránky jsou realizovány jako formuláře složené z komponent a tyto celé stránky jsou odesílány na server, kde probíhá zpracování. Speciální funkcí je pak ViewState, který dokáže udržovat stav stránky (musí se držet stav komponent), ačkoliv protokol HTTP je bezstavový. Ve WebForms se odděluje pouze vrstva zobrazení a aplikační vrstva, další rozložení logiky je pak pouze na programátorovi. Druhým přístupem na platformě .NET je ASP.NET MVC. Tento vzor striktně odděluje jednotlivé vrstvy aplikace (respektuje princip 3-vrstvé architektury). Oproti předchozímu přístupu nabízí programátorovi větší volnost při vývoji. Metody, které se starají o předávání hodnot, volání funkcí a udržování stavů jsou plně pod kontrolou tvůrce. Také poskytují lepší možnosti pro řešení autorizace jednotlivých uživatelů. ASP.NET MVC Na základě srovnání byl vybrán tento přístup. Největší předností je oddělení jednotlivých

vrstev,

které

je

možné

udržovat

nezávisle

na

sobě.

Z implementačního hlediska se jedná o jednodušší a přehlednější zdrojové kódy. Mezi další přednosti patří definice objektů a jejich vlastností – bude podrobněji vysvětleno dále. Jedná se o webový aplikační Framework od společnosti Microsoft, která implementuje návrhový vzor Model-View-Controller. Při realizaci byla využita poslední dostupná verze 45. Obrázek 22 ukazuje, jak jednotlivé vrstvy fungují při interakci s uživatelem. Uživatel volá odkazy na webové stránce. Tyto odkazy představují akce příslušného Controlleru, může se jednat o GET nebo POST událost. Při události POST dochází

5

ASP.NET MVC 4 byla vydána 14. srpna 2012.

48

k překladu pomocí nastavení směrování (Routing)6 v aplikaci na akci Controlleru. Controller na základě konkrétní implementace provede sekvenci kódu a vrací uživateli zpět View ve formě webové stránky. Controller využívá vrstvu Model, ve které jsou obsaženy objekty, se kterými pracuje (tyto objekty může načítat z databáze).

Obrázek 22: Sekvenční diagram pro Controller (8)

Implementace

informačního

systému

je

celá

řešena

v technologiích

od společnosti Microsoft. Použité technologie a produkty:  Visual Studio 2012 Professional7  Framework 4.5  ASP.NET MVC 4  IIS Expres  SQL Server Express Database 2012 Produkty jsou volně ke stažení ze stránek výrobce. Nebylo tedy nutné investovat do

žádného

speciálního

software.

Aplikace

je

kompletně

napsána

v programovacím jazyku C#.

Routing definuje, jak budou nastaveny cesty v aplikaci – jedná se o dynamické nastavení odkazů, kde není nutné psát konkrétní cestu. V aplikaci můžou existovat různá směrování pro různé Controllery. 7 Tato verze software byla použita na základě akademické licence Microsoft Development Network Academic Alliance (http://ui.pefka.mendelu.cz/cs/technika/msdnaa). 6

49

5.1 Adresářová struktura Projekt je členěn z pohledu logiky do několika adresářů, kde každý má svůj význam a specifický obsah. Zde je uveden výčet těch nejdůležitějších adresářů: o App_Start Třídy pro definici nastavení aplikace po spuštění. Významné je třída RouteConfig.cs, která definuje, jak budou směrovány URL adresy. Výchozí nastavení je {controller}/{action}/{id}. o Content Soubory kaskádových stylů pro vzhled aplikace a grafika. o Controllers Třídy pro logiku aplikace. Adresář obsahuje Controller pro každý subsystém. o DAL (Data Access Layer) Třídy, které se starají o přístup k datům a manipulaci s databází (datové vrstvě). Pro přístup k datům byl využit návrhový vzor Repository. Každá třída zajišťuje přístup ke konkrétním doménovým entitám a má své metody. Pro přístup k více druhům objektů z jednoho Controlleru musí být vytvořena vždy instance daného Repository. o Helpers Pomocné třídy, které se například starají o řízení autentizace a autorizace v aplikaci. o Models Třídy, kde jsou definovány všechny bussiness objekty a jejich vlastnosti. o ViewModels Speciální typ tříd, které slouží pro zobrazení objektů z různých tříd. Zde jsou uloženy třídy, které slouží pro předávání více druhů dat do View. Protože v rámci řadiče je možné předávat pouze jeden typ objektu, existují třídy ViewModels jejíž strukturu můžou tvořit různé objekty. Objektem je myšlena, jak konkrétní instance, tak kolekce.

50

o Views Webové stránky pro zobrazení. Pomocí prvků HTML zobrazují předávané objekty. Jsou založeny na doménových modelech nebo zobrazovacích modelech (ViewModels). Další adresáře obsahují především referenční knihovny pro .NET, JavaScript nebo AJAX. V rámci projektu existuje i několik konfiguračních souborů, z nichž nejvýznamnější je soubor web.config. Zde je uloženo připojení k databázi a pověření, konfigurace SMTP pro odesílání emailů nebo nastavení autentizační a registrační poskytovatelů.

5.2 Controllers Nejdůležitější třídy v projektu. Starají se o logiku aplikace a jejich úlohou je zajistit interakci mezi uživatelem a ostatními částmi systému. Uživatel volá jednotlivé akce (metody) Controlleru. Ve většině případů existuje implementace metody pro GET událost, která vrací uživateli data, ale existuje i pro událost POST, která odesílá data a ukládá je do databáze. Pro každý subsystém existuje v řešení vlastní Controller: o AccountController Zajišťuje správu uživatelských účtu a hesel. o CategoryController Správa kategorií a soupisek. o DocumentController Správa dokumentů, jejich ukládání do databáze a zpětné načítání. o ExternalPersonController Správa externích osob (kontaktů). o MemberController Správa členů. o MembershipFeeController Správa členských příspěvků. o RequirementController Správa požadavků.

51

o RoleController Správa rolí a přiřazování uživatelů do rolí. o TeamController Správa týmů. o TravelOrderController Správa cestovních příkazů. Třídy se starají o zobrazovaná data a o jejich vytváření, editaci a mazání. Plus jsou doplněny o vlastní operace.

5.3 Models Adresář obsahuje definici jednotlivých tříd z fáze návrhu systému. Každá třída je reprezentována samostatným souborem. Soubor obsahuje seznam použitých knihoven (referencí), které se v rámci třídy používají. A dále definici atributů a jejich datových typů. Některé atributy jsou doplněné o vlastnosti Data Annontation, které určují, jak budou uloženy v databázi.

5.4 Views Tento adresář obsahuje všechny webové stránky, které se zobrazují uživateli. V adresáři jsou tyto stránky uloženy v podadresářích, jejichž název odpovídá příslušenému Controlleru. Názvy stránek pak odpovídají jednotlivým metodám v Controlleru. Pokud uživatel volá metodu řadiče, je mu vráceno konkrétní View jako návratový typ metody, nikoliv klasický odkaz jen je tomu v běžných HTML stránek. View obsahuje předávaný objekt nebo kolekcí objektů, se kterými se pak dále pracuje v rámci Razor syntaxe. Pro zobrazení je využit Razor View Engine, což je technologie, která kombinuje prvky jazyka HTML a programovacího jazyka. Koncovka souborů je .cshtml, což označuje použití programovacího jazyka C#.8 Každé View může být založeno na konkrétní třídě (jedná se tzv. o „silně typové“ View), které pak očekává předání objektu dané třídy. V rámci definice

8

V případě použití jazyka Visual Basic by přípona souboru byla .vbhtml.

52

typu třídy lze v této syntaxi pracovat s elementy HTML, které jsou založené právě na modelu třídy a jeho atributech.

Na View je pak možné pracovat i s validacemi pro atributy třídy. Jejich definice bude vysvětlena v následující kapitole.

5.5 Datová vrstva a databáze O práci s daty se stará Entity Framework (EF). Entity Framework je součástí platformy .NET9. Jedná se objektově-relační mapovací (Object-Relation Mapping) technologii, která se snaží eliminovat nesoulad mezi konstrukcemi objektověorientovaného programování v .NET a konstrukcemi relačních dat v databázovém sytému. (2) Tento Framework se stará o ukládání objektů do databáze a dokáže je zpětně opět načítat ve formě objektů (zajišťuje jejich automatickou konverzi). EF podporuje i základní operace jako je vytváření, načítání, aktualizování a mazání objektů. Pro získávání dat a tvorbu dotazů existuje speciální dotazovací jazyk LINQ (Language Integrated Query). Jeho syntaxe je podobná jako SQL (Structured Query Language), který je určen pro práci s daty přímo nad relační databází. Ukázka syntaxe jazyka pro získání kolekce objektů: var members = from m in context.Members where m.EndActivityDate == null orderby m.LastName descending select m;

Jazyk umožnuje provádět i zjednodušenou formu tvorby dotazů ve formě lambda výrazů: var members = context.Members.Where(m => m.EndActivityDate == null).OrderByDescending(m => m.LastName);

9

Framework .NET 4.5 používá Entity Framework 5

53

Načítání souvisejících dat Pro načítání souvisejících dat (atributem objektu je jiný objekt nebo kolekce objektů) je využita strategie Lazy Loading. Podle (9) když je načtena entita, nejsou současně související data načtena. V okamžiku, kdy se poprvé pokusíme přistoupit k navigační vlastnosti, která data vyžaduje, jsou automaticky získána. Výsledkem je více dotazů do databáze, první když načteme samotný objekt a poté pokaždé, když přistupujeme k jeho vlastnostem. Každá vlastnost objektu pak musí obsahovat klíčové slovo virtual. Předností tohoto přístupu je zrychlení načítání dat, pokud nepotřebujeme přistupovat k souvisejícím datům ihned, a tím zrychlení celé aplikace. Veškerá data aplikace jsou uložená v relační databázi na SQL Serveru. Objekty a jejich vazby v databázi byly vygenerovány při první inicializaci aplikace na základě implementovaných tříd. Tvorba datového modelu V rámci EF byl využit přístup „Code First“, kdy je nejdříve provedeno kódování a databáze je vytvořena na základě modelu. Při změně modelu lze jednoduše znovu vygenerovat databázi. Tento přístup poskytuje programátorům mít kontrolu nad tím, jak budou data ukládána a to bez nutnosti tuto část řešit na straně databáze. Data Annontation Datové anotace v EF slouží pro definování struktury objektů pro uložení v databázi. Na této úrovni může vývojář specifikovat vlastnosti a omezení pro jednotlivé atributy. Patří sem definice názvu uložené tabulky, název sloupce, mapování primárních a cizích klíčů, minimální a maximální délka atributu, nutnost jeho vyplnění nebo jak má být atribut v aplikaci zobrazován. Ukázka specifikace atributu příjmení: [Display(Name = "Příjmení")] [Required(ErrorMessage = "Příjmení musí být vyplněno.")] [MinLength(2), MaxLength(30)] [StringLength(30)] public string LastName { get; set; }

54

Dále lze na této úrovni definovat rozsah intervalu, přípustné hodnoty nebo psát vlastní regulární výrazy. V aplikaci byly využity regulární výrazy pro zadávání telefonních čísel a emailů. Data Annontation umožňuje i psaní vlastních kontrol a pravidel. Tyto omezení lze pak aplikovat i na úrovni uživatelských vstupů u validace polí. Uživateli je na úrovni View vrácena chyba. Tím je splnění požadavku, kde bylo definováno, že při ukládání dat musí být zaručeno, že údaje budou validní a budou mít požadovaný formát. Toho bylo docíleno také pomocí této funkcionality. Třída DbContext Class Při využití „Code First“ je branou do databáze třída odvozená od DbContext třídy. Odvozená třída má jednu nebo více vlastností typu DBSet, kde T reprezentuje objekt, který má být chováván. (10)

5.6 Řízení práv pro role Zabezpečení funkcí pro různé role je řešeno na dvou úrovních. První úroveň je na vrstvě View, kde je zobrazení odkazů pro využití funkcí podmíněno rolí uživatele. Uživatel, který není v roli, tyto odkazy nevidí. Nejsou vykresleny v rámci HTML stránky. To zajišťuje syntaxe Razor. V ukázce je vidět přístup k odkazu pro vytvoření nového člena je jen pro roli Sekretář: @if(User.IsInRole("Sekretář")) {

@Html.ActionLink("Vytvořit člena", "Create")

}

Druhým místem, kde je řešen přístup uživatelů, je na úrovni Controlleru. U každé akce, kde je potřeba rozlišit přístup pro role je uveden výčet těchto rolí. Pokud uživatel není aktivní záznam v historii, bude vyzván k přihlášení.

55

Ukázka kontroly role opět pro roli Sekretář a vytvoření člena: [Authorize(Roles = "Sekretář")] public ActionResult Create()

Kontrola je pro obě implementace akce (GET i POST).

5.7 Nasazení Aplikace byla nasazena do testovacího prostředí. Jedná se o testovací verzi aplikace (beta verzi), která není určena pro nasazení přímo do provozu. Aplikace je dostupná na adrese http://isfk.mhis.cz. Seznam testovacích uživatelů a jejich přístupových údajů je uveden v příloze B. Pro testování byla vytvořena ukázková testovací data. Při nasazení aplikace na server byla provedena migrace projektu přes FTP připojení. Adresářová struktura byla překopírována pro určeného podadresáře na serveru webshotingu. Dále byla přenesena i databáze. Ačkoliv projekt by byl schopen vygenerovat strukturu databáze podle modelu, nebyla by v něm data z testovacího prostředí, a proto byl zvolen přenos celé DB. Dále bylo pro nové prostředí nutné provést změny v konfiguračních souborech. Byl změněn řetězec pro připojení k databázi a zadaná nová pověření. A bylo změněno zobrazování chyb, kdy aplikace v případě pádu nebo nemožnosti připojení k databázi, bude poskytovat uživatelům vlastní upozornění a ne přímo systémovou chybu.

56

6. Výsledky a diskuze 6.1 Zhodnocení a přínosy Na základě zkušebního provozu bylo možné vyhodnotit přínosy a nedostatky systému. Systém byl nasazen v testovacím prostření jako beta verze systému a byla v něm vytvořena testovací data pro ověření funkcionalit a požadavků. Tvorba dat byla v kompetenci testovacích uživatelů. Přístup k systému byl umožněn jen pro uživatele, kteří se podíleli na jeho analýze a vývoji. Scénáře pro testování odpovídaly reálným situacím, které souvisí s chodem klubu.

Obrázek 23: Ukázka obrazovky systému „Adresář členů"

Informační systém splnil očekávané předpoklady a pokryl všechny požadavky na něj kladené. Uživatelé ocenili funkcionalitu odesílání e-mailů po vytvoření požadavku a možnost vyhodnotit požadavek v co nejkratší době. Uživatelé mají přehled nad aktuálním stavem požadavku. Celkově systém shledali jako vyhovující a plně dostačující. V praxi se od systému očekává, že zefektivní činnosti související s chodem klubu a podpoří rozhodovací procesy. Informace jsou centralizované na jednom místě, řazeny přehledně s možností prohlížení podrobností. Odpadá nutnost využívat jiné systémy, dohledávat informace v emailové korespondenci nebo si informace ukládat do vlastních souborů a evidencí. Členové realizačních týmu družstev ocenili přehlednost „Adresáře členů“, který poskytuje nezbytné informace nejen o členech své kategorie a tím jim umožňuje snadnější komunikaci s každým členem klubu.

57

Připomínky byly kladeny zejména na uživatelské rozhraní, které bylo pro testování navrženo. Uživatelé by chtěli lépe strukturované formuláře nebo „našeptávače“ při psaní do polí pro vyhledávání.

Obrázek 24: Ukázka obrazovky pro vytvoření cestovního příkazu

Informační systém v porovnání se současným stavem znamená zrychlení procesů a komunikace, snížení nákladů na administrativní procesy, protože není nutné vše vyřizovat osobně nebo telefonicky.

6.2 Ekonomické zhodnocení projektu Při implementaci bylo využito vývojových prostředků, které jsou k dispozici na internetu ve formě bezplatných licencí10. Náklady na aplikaci vznikají až při jejím nasazení na internet. Klub disponuje předplaceným prostorem pro provoz webových stránek. Tento prostor poskytuje „nadstandardní“ podmínky pouze pro provoz webové prezentace. Při zakoupení již bylo počítáno, že bude v budoucnu zaveden nějaký informační systém. Takže tyto náklady se musejí zohlednit při vyčíslení nákladů na systém. Náklady na pronájem webhostingu činí 205 Kč (169 Kč bez DPH) měsíčně. Jedná se o variantu ASP.NET Optimal11. Roční částka je pak 2 460 Kč (2 028 Kč bez

Ačkoliv bylo při vývoji v rámci akademické licence využito komerční verze produktu Visual Studio 2012, lze aplikaci stejně naprogramovat i Express verzi produktu. 11 Ceník a srovnání variant je dostupné zde: http://www.web4u.cz/cs/webhosting/asp-netwebhosting. 10

58

DPH) za rok. Společnost WEB4U s.r.o. navíc poskytuje slevu 10% při ročním předplatném. Částka za roční pronájem je pak 2 216 Kč (1 825 Kč bez DPH) za rok. V této ceně není uváděna částka za pronájem domény. Tato doména je již placena pro účely webové prezentace a domény III. řádu, kde bude provozován informační systém, nejsou zvlášť zpoplatňovány. Cena za prodloužení pronájmu domény je 152 Kč (125 Kč bez DPH) za rok. Pro produkční prostředí bude dále nutné zakoupit SSL certifikát, aby byla zabezpečena komunikace mezi klientem a serverem přes protokol HTTPS. To znamená mít od poskytovatele pronajatou vlastí IP adresu v ceně 150 Kč za měsíc (1 800 Kč za rok). Pak si od certifikační autority nechat certifikát pro danou IP adresu ověřit. Cena se pohybuje od stovek korun po několik tisíc korun, záleží na autoritě, a zda je certifikát pro jednu doménu nebo všechny subdomény v rámci domény. Zakoupení vlastního serveru z hlediska finančních prostředků není pro klub reálné. Nákup serveru by obnášel další náklady na správu a prostory.

6.3 Možnosti rozšíření Už v průběhu testování se objevily návrhy na možnost rozšíření systému. Tyto funkcionality ovšem nebyly specifikovány při prvotní analýze, a proto nebyly zahrnuty do návrhu. Před nasazením systému do ostrého provozu bude proveden další cyklus analýzy a vývoje, ve kterém budou některá tato rozšíření podrobně specifikována a následně implementována. Výstupy ze systému V současném provedení systém nepodporuje žádný způsob exportu dat. Všechna data jsou uložena v databázi a přístupné pouze přes rozhraní webového prohlížeče. Toto rozhraní není optimalizováno pro tiskové výstupy. Uživatelé by uvítali možnost exportovat data v přehledné formě do formátu, který by byl vhodný pro tisk. Nebo export do tabulkového editoru, kde bylo možné provést další úpravy a pak provést tisk.

59

Registrační modul Registrační modul byl součástí systému, ale jeho rozhraní bylo publikováno jako formulář přístupný veřejně nebo pod přístupovým jménem a heslem. Tento subsystém by sloužil hráčům a externím osobám pro registrace na akce pořádané florbalovým klubem. Jedná o akce typu letní soustředění, florbalové kempy, florbalové turnaje nebo zájezdy na extraligové a mezinárodní zápasy. Registrace na tyto akce probíhá formou přihlašování přes přihlášky v tištěné nebo naskenované podobě a pro jejich evidenci je pak nutné, zpětně je zadat to počítače. Komunikace s účastníky je pak řešena individuálně. Členové vedení by v tomto modulu měli možnost sledovat a evidovat přihlášené uživatele podle akce. A po akceptaci přihlášky nebo zadání platby by měli uživatelé zpětnou vazbu přes např. emailovou notifikaci. Subsystém by bylo možné využít i interně pro řešení pořadatelských služeb na domácí turnaje. Hromadná komunikace Vedoucí družstev by uvítali mít možnost komunikovat hromadně s celou svou kategorií a to pomocí zasílaní emailových nebo SMS zpráv, protože v současné době neexistuje jednotný prostředek. Komunikace je částečně řešena na stávajících internetových stránkách klubu v zabezpečené sekci pro členy, ale ne všichni hráči tam mají přístup, protože je nutné mít vlastní jméno a heslo

pro přihlášení.

Dalším prostředkem jsou email, telefon nebo sociální sítě. Dále by bylo možné systém potencionálně rozšířit o tyto funkcionality: Rozšíření přístupu pro všechny členy Tato verze systému poskytuje funkce a informace určené vedení a vedoucím pracovníkům. V úvahu připadá i zpřístupnění informačního systém pro hráče. S tím souvisí vytvoření dalšího subsystému, který bude pro ně určený. V úvahu připadá subsystém pro správu docházky na tréninkové jednotky, kde by hráči omlouvali svou neúčast na tréninkových jednotkách. Další variantou je subsystém pro přihlašování dopravy na soutěžní zápasy, kde by mohl být harmonogram jízd, aby doprava byla rozložena mezi všechny členy.

60

Mobilní verze systému Současná verze systému je primárně implementována pro použití přes webový prohlížeč v počítači. Přístup přes mobilní zařízení je sice možný, ale aplikace není přizpůsobená pro tento způsob zobrazení. Mohou se objevovat chyby vizualizace nebo i funkčnosti. Vzhledem k trendům poslední doby, jako jsou chytré telefony a tablety, by bylo možné implementovat verzi systému pro mobilní platformu.

6.4 Diskuze Problematika informačních systémů a jejich návrhu nabízí velké množství řešení a alternativ, jak systém namodelovat a implementovat. V tomto řešení byl použit v dnešní době asi nejrozšířenější způsob, tedy objektově orientovaný přístup, pro který hovoří především kladné zkušenosti z řad analytiků a programátorů z praxe. Systém je navržen pro potřeby konkrétního klubu a potřeby uživatelů. Při analýze a návrhu byla začleněna jeho organizační struktura a procesy, které souvisí s chodem klubu. Aplikace je dostupná z prostředí internetu. Uživatelé k ní mohou přistupovat bez omezení na čas nebo místo. Implementace byla provedena s použitím moderního frameworku pro webové aplikace. Ten umožní systém lépe spravovat, testovat

a

implementovat

případná

rozšíření.

Poskytuje

i

možnosti

pro zabezpečení aplikace. Na základě testovací provozu byly navrženy další požadavky, které budou zaimplementovány před nasazením do ostrého provozu. Potom by bylo vhodné při nasazení do ostrého provozu dodržet souběžnou strategii pro nasazení systému. Po určitý časový interval by fungoval současný model fungování klubu bez IS a zároveň i tento nově navržený systém.

61

7. Závěr Cílem diplomové práce bylo realizovat informační systém pro potřeby florbalového klubu. Tento systém měl pomoci pracovníkům klubu zjednodušit a zefektivnit jejich práci. V diplomové práci byl využit moderní objektově orientovaný přístup k vývoji aplikací a systémů. Práce obsahuje teoretickou část, kde jsou popsána teoretická východiska práce. V další fázi práce byla provedena analýza současného stavu a definice požadavků, které vyplývají z aktuálních potřeb uživatelů. Fáze analýzy byla provedena pomocí základních prostředků notace UML 2.0 a byl vytvořen i návrh systému. Realizace systému byla provedena na základě výstupů analýzy. Model systému byl převeden do technologie ASP.NET MVC. Při implementaci byl kladen důraz na využití návrhových vzorů pro oddělení jednotlivých částí aplikace a tím udržet aplikaci jednodušší pro správu a údržbu. Při řešení byl zvolen přístup, který umožnil i databázové uložení ošetřit na úrovni kódu programu. Výsledné řešení bylo nasazeno do testovacího provozu jako beta verze systému a byl umožněn přístup uživatelům. Bylo možné porovnat finální řešení s představou klienta. Řešení bylo akceptováno, protože splňuje zadané požadavky a podporuje jednotlivé činnosti pro řízení klubu. Práce umožnila spojit teoretické poznatky a jejich konkrétní využití v praxi. Velmi přínosné bylo řešit celý životní cyklus vývoje systému, což mi poskytlo velmi cenné zkušenosti pro využití v dalších projektech.

62

8. Bibliografie 1. Konečný, Vladimír. Integrované informační systémy. Brno : Mendelova univerzita v Brně, 2010. Skripta do předmětu. 2. Clark, Dan. Beginning C# Object-Oriented Programming. New York : Apress, 2011. 978-1-4302-3530-9. 3. Arlow, Jim a Neustadt, Ila. UML 2.0 a unifikovaný proces vývoje aplikací. Brno : Computer Press, a.s., 2007. ISBN 978-80-251-1503-9. 4. Kraval, Ilja. Analytické modelování informačních systémů pomocí UML v praxi. Valašské Klobouky : Object Consulting, 2010. 5. Millett, Scott. PROFESSIONAL ASP.NET Design Patterns. Indianopolis : Wiley Publishing, Inc., 2010. ISBN 978-0-470-29278-5. 6. Čada, Ondřej. Objektové programování. Praha : Grada Publishing, a.s., 2009. ISBN: 978-80-247-24745-5. 7. Microsoft. MSDN - The Repository Pattern. Microsoft Develo. [Online] Microsoft Developer Network. [Citace: 13. 11 2012.] . 8. Ochodek, Mirosław. http://www.se.cs.put.poznan.pl. Software Engineering Portal. [Online] 02. Únor 2010. [Citace: 20. 12 2012.] . 9. Dykstra, Tom. ASP.NET - Getting Started with EF using MVC. ASP.NET. [Online] 11. 04 2011. [Citace: 01. 10 2012.] . 10. Galloway, Jon, a další, a další. Profesional APS.NET MVC 4. Indianopolis : Wiley Publishing, Inc., 2012. ISBN 978-1-118-34846-8. 11. Freeman, Adam a Sanderson, Steven. ASP.NET MVC3 Framework. 3. místo neznámé : Apress, 2011. ISBN 978-1-4302-3405-0.

63

12. Guthrie, Scott. ScottGu's Blog. ScottGu's Blog. [Online] 02. 7 2010. [Citace: 01. 12 2012.] http://weblogs.asp.net/scottgu/archive/2010/07/02/introducingrazor.aspx. 13. Chadwick, Jess, Snyder, Todd, Hrusikesh, Panda. Programming ASP.NET MVC 4. Sebastopo : O’Reilly Media, Inc., 2012. ISBN 978-1-449-32031-7. 14. Esposito, Dino. Comparing Web Forms And ASP.NET MVC. MSDN Magazine. [Online] MSDN, 01. 06 2009. [Citace: 07. 10 2012.] . 15. MSDN. ASP.NET MVC Overview. [Online] MSDN. [Citace: 11. 03 2012.] .

64

9. Seznam zkratek a pojmů Zkratka CMS ČFbU DB EF FTP HTML HTTP IS LINQ MVC OOA OOD OOP ORM SMTP SQL SSL UI UML XML

Význam Content Management System Česká florbalová unie Databáze Entity Framework File Trasfer Protocol HyperText Markup Language Hyper Text Transfer Protocol Informační systém Language Integrated Query Model-View-Controller Objektově orientovaná analýza Objektově orientovaný návrh (design) Objektově orientované programování Objektově relační mapování Simple Mail Transfer Protocol Structured Query Language Secure Socket Layer User Interface Unfield Model Language Extensible Markup Language

65

10. Přílohy A. DVD médium Médium obsahuje: -

Diplomovou práci v elektronické podobě

-

Projekt a zdrojové kódy

-

Vývojové nástroje

-

Databázi s testovacími daty

B. Přístupy k řešení Role uživatele: Předseda Sekretář Pokladník Člen vedení Člen vedení Hlavní trenér Vedoucí družstva

Kategorie: Klub Klub Klub Klub Klub Muži A Starší žáci

Přihlašovací jméno: predseda sekretar pokladnik clenvedeni1 clenvedeni2 trenermuzia vedoucistz

66

Heslo: .predseda. .sekretar. .pokladnik. .clenvedeni1. .clenvedeni2. .trenermuzia. .vedoucistz.