Analýza a návrh informačního systému příspěvkové organizace DDM Tišnov

Mendelova univerzita v Brně Provozně ekonomická fakulta

Analýza a návrh informačního systému příspěvkové organizace DDM Tišnov Bakalářská práce

Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D.

Jan Helán

Brno 2014

Na tomto místě bych rád poděkoval především paní doc. Ing. Ivaně Rábové, Ph.D. za vedení, cenné rady a připomínky při tvorbě této bakalářské práce. Dále bych také rád poděkoval panu doc. Ing. Dr. Jiřímu Rybičkovi za vytvoření a publikaci šablony pro sazbu závěrečných prací a také pracovníkům DDM Tišnov za možnost nahlédnutí do interních záležitostí a chodu organizace.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Návrh a analýza informačního systému příspěvkové organizace DDM Tišnov vypracoval/a samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 2. února 2014

_______________________________

Abstract Helán, J. Analysis and design of information system contributory organization DDM Tišnov. Bachelor thesis. Brno: Mendel University, 2014. This thesis deals with analysis of current state of information processing suin the contributory organization DDM Tišnov, creating a suitable model of information system for the organization and implementation part of the system into working web application. Part of this thesis is an economic evaluation of the proposal, including the hardware. Keywords Bachelor thesis, DDM Tišnov, proposal, analysis, information system, web application.

Abstrakt Helán, J. Analýza a návrh informačního systému příspěvkové organizace DDM Tišnov. Bakalářská práce. Brno: Mendelova Univerzita v Brně, 2014. Tato bakalářská práce se zabývá analýzou současného stavu zpracování informací v příspěvkové organizaci DDM Tišnov, vytvořením vhodného modelu informačního systému pro tuto organizaci a implementací části systému do funkční webové aplikace. Součástí práce je ekonomické zhodnocení návrhu, včetně hardwarového vybavení. Klíčová slova Závěrečná práce, DDM Tišnov, návrh, analýza, informační systém, webová aplikace.

Obsah

9

Obsah 1

2

3

Úvod a cíl práce

13

1.1

Úvod....................................................................................................................................... 13

1.2

Cíl práce................................................................................................................................ 13

Metodika zpracování

14

2.1

Zvolený přístup ................................................................................................................. 14

2.2

Analýza problému ............................................................................................................ 14

2.3

Návrh řešení problému .................................................................................................. 14

2.4

Implementace .................................................................................................................... 14

2.5

Testování ............................................................................................................................. 14

Objektová analýza

15

3.1 Jazyk UML ............................................................................................................................ 15 3.1.1 Diagram případu užití .......................................................................................... 16 3.1.2 3.2 4

Diagram tříd ............................................................................................................. 17

Diagram entit ..................................................................................................................... 18

Použité jazykové prostředky 4.1

19

ASP.NET ............................................................................................................................... 19

4.1.1

Představení ............................................................................................................... 19

4.1.2 4.1.3

.NET Framework .................................................................................................... 19 Kompilace, vícejazyčnost a CLR ........................................................................ 19

4.1.4 4.1.5

Webové formuláře a jiné vysokoúrovňové funkce.................................... 20 Serverové ovládací prvky.................................................................................... 21

4.1.6 4.1.7

Modely tvorby kódu a jejich vazby .................................................................. 22 Obsluha událostí ..................................................................................................... 23

4.1.8

Zpracování a životní cyklus stránky ............................................................... 24

4.1.9

Vývojové prostředí ................................................................................................ 26

4.2

Prezentační vrstva ........................................................................................................... 26

4.2.1

HTML a CSS ............................................................................................................... 26

4.2.2 4.2.3

JavaScript................................................................................................................... 27 AJAX ............................................................................................................................. 28

4.2.4

Knihovna jQuery ..................................................................................................... 29

10

Obsah

4.3

Aplikační vrstva................................................................................................................. 30

4.3.1 5

6

C# .................................................................................................................................. 30

Analýza současného stavu

31

5.1

Popis organizace ............................................................................................................... 31

5.2

Model informačního systému DDM ........................................................................... 32

5.2.1

Specifikace požadavků ......................................................................................... 32

5.2.2 5.2.3

Diagram případu užití ........................................................................................... 33 Diagram tříd ............................................................................................................. 36

5.2.4

Entitně relační diagram systému ..................................................................... 37

Návrh řešení

38

6.1 Rozvržení stránky ............................................................................................................ 38 6.1.1 Základní prvky stránky ........................................................................................ 38 6.1.2 Doplňující prvky stránky ..................................................................................... 39 6.2

Role a oprávnění uživatelů ........................................................................................... 40

6.3

E-přihláška .......................................................................................................................... 41

6.4

Činnosti DDM ..................................................................................................................... 42

6.4.1 6.4.2

Evidence činností.................................................................................................... 42 Detail činnosti .......................................................................................................... 43

6.4.3

Přidání člena do činnosti ..................................................................................... 44

6.5

6.5.1

Evidence členů ......................................................................................................... 45

6.5.2

Detail člena DDM .................................................................................................... 46

6.6

7

Členové činností DDM ..................................................................................................... 45

Přihlášky DDM ................................................................................................................... 47

6.6.1

Evidence přihlášek ................................................................................................. 47

6.6.2

Detail přihlášky ....................................................................................................... 47

Diskuze

48

7.1

Testování ............................................................................................................................. 48

7.2

Ekonomické zhodnocení ................................................................................................ 48

7.3

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

8

Závěr

50

9

Literatura

51

A

Obsah přiloženého DVD

53

Seznam obrázků

11

Seznam obrázků Obr. 1

Kompilace webové stránky ASP.NET

20

Obr. 2

Životní cyklus stránky ASP.NET

25

Obr. 3

Ukázka stromové struktury HTML dokumentu pomocí DOM

28

Obr. 4

Diagram případu užití organizace DDM Tišnov

33

Obr. 5

Diagram tříd organizace DDM Tišnov

36

Obr. 6

ER diagram informačního systému DDM Tišnov

37

Obr. 7

Hlavička stránky

38

Obr. 8

Ukázka drobečkové navigace na stránce Detail přihlášky

38

Obr. 9

Primární navigační panel

39

Obr. 10

Filtrace činností na stránce Evidence činností

39

Obr. 11

Informační panel zobrazující účastníky činnosti

39

Obr. 12

Přihlašovací formulář

40

Obr. 13

Webová stránka Evidence činnosti v DDM Tišnov

42

Obr. 14

Webová stránka Detail činnosti Základy práce na PC

43

Obr. 15

Modální okno pro přidání člena do činnosti

44

Obr. 16

Výřez webové stránky Evidence členů

45

Obr. 17

Webová stránka obsahující Detail člena

46

Obr. 18

Webová stránka Detail přihlášky

47

12

Seznam tabulek

Seznam tabulek Tab. 1

Počty účastníku k 31. 10. 2012

31

Tab. 2

Odhad nákladů na pořízení IS

49

Úvod a cíl práce

13

1 Úvod a cíl práce 1.1

Úvod

V dnešní době jsou přesné informace a jejich rychlé vyhledání klíčem k úspěšnému zvládnutí všech manažerských rozhodnutí. Proto je velkým trendem posledních let nasazování informačních systémů i do příspěvkových a dalších organizací. Informační systémy poskytují lepší kontrolu a přístup k uloženým informacím, ve srovnání s ručním vyhledáváním informací v dokumentech umístěných v různých složkách. Dům dětí a mládeže v Tišnově jsem navštěvoval od svého dětství a vyplňováním přihlášek do různých kroužků jsem nevědomky zvětšoval množství ukládaných dokumentů. Dnes už DDM nenavštěvuji, zato si ale uvědomuji, kolik nezáviděníhodné práce mají řídící pracovníci s evidencí těchto dokumentů, proto při rozhodování o tvorbě informačního systému padla má volba právě na tuto organizaci.

1.2

Cíl práce

Cílem práce je na základě analýzy datových toků v příspěvkové organizaci Dům dětí a mládeže navrhnout a implementovat část informačního systému v podobě webové aplikace, která umožní pracovníkům jednodušší práci s evidencemi přihlášek a účastníků činností a také správu těchto činností. Návštěvníkům DDM dále nabídne možnost vyplnění přihlášky elektronickou formou, čímž přispěje k zefektivnění a větší automatizaci některých podnikových procesů. Součástí návrhu je také ekonomická analýza nákladů pro zavedení informačního systému a zhodnocení tohoto řešení.

14

Metodika zpracování

2 Metodika zpracování 2.1

Zvolený přístup

Pro analýzu, návrh a implementaci informačního systému jsem zvolil objektově orientovaný přístup, který nahlíží na informační systém jako na kolekci komunikujících objektů a umožňuje jednodušší rozšiřitelnost tohoto systému.

2.2

Analýza problému

Při návrhu informačního systému bylo nutné nejprve zjistit, jaké úlohy by měl tento systém zvládat. Díky konzultacím s paní ředitelkou DDM Tišnov jsem získal přehled o jednotlivých úkonech, které by měla výsledná webová aplikace umět řešit. Tyto úkony byly sepsány do seznamu funkčních a nefunkčních požadavků na systém a později byly použity pro tvorbu diagramu případu použití.

2.3

Návrh řešení problému

Po provedení prvotní analýzy bylo potřeba získané informace reprezentovat. Pro toto znázornění byly využity prvky grafického jazyka UML. Dynamické chování systému bylo popsáno použitím diagramu případu použití (tzv. Use Case diagram) a pro popis statické struktury systému byl použit diagram tříd (tzv. Class diagram). Oba tyto diagramy byly realizovány pomocí CASE nástroje Visual Paradigm for UML, který mohou všichni studenti Provozně ekonomické fakulty bezplatně využívat. Poslední částí návrhu bylo zhotovení nástinu uživatelského vzhledu aplikace. Pro tuto fázi návrhu se mi nejvíce osvědčily klasické nástroje – tužka a papír, které se ukázaly jako nejefektivnější.

2.4

Implementace

Dalším logickým krokem byla transformace návrhu do kódu a vytvoření webové aplikace. Vzhledem k objektově orientovanému návrhu jsem zvolil implementaci na platformě .NET, konkrétně pomocí kombinací technologie ASP.NET a programovacího jazyka C#. Dále byly použity jazyky HTML, CSS, JavaScript a SQL. Implementace probíhala ve vývojovém prostředí Visual Studio 2010 od firmy Microsoft, které je volně dostupné díky univerzitní licenci pro studenty PEF.

2.5

Testování

Poslední částí vývoje informačního systému bylo testování funkcionality výsledné webové aplikace na testovacích datech, poskytnutých organizací DDM Tišnov a diskuze s pracovníky organizace ohledně uživatelského prostředí aplikace.

Objektová analýza

15

3 Objektová analýza V minulosti byl vývoj programového kódu pro většinu webových aplikací pojat strukturovaně. Aplikace byla rozdělena na funkční a datovou část a analytický návrh probíhal téměř pouze v datové části. Složitost programů narůstala a vznikaly problémy v propojení a soudržnosti datové a funkční vrstvy. Dalším problémem bylo velmi složité provádění změn, údržba a další rozšiřování systému. Z těchto důvodů se ve světě začal čím dál více používat objektově orientovaný přístup, který umožňuje zvýšení produktivity vývojářských prací. Toto zlepšení je důsledkem důkladnější analýzy, návrhu a efektivnějšího programovaní. Pro potřeby analýzy a návrhu je jedním z nejpropracovanějších přístupů použití unifikovaného modelovacího jazyka UML. (Schmuller, 2001)

3.1

Jazyk UML

V dřívějších dobách výpočetní techniky se programátoři obvykle příliš nespoléhali na hloubkové analýzy problému. Vývoj systému byl víceméně založen na metodě „pokus omyl“. Programátoři sami psali program celý od začátku do konce a doufali v příznivý výsledek. Často však docházelo k problémům vzniklým nedostatečnou komunikací mezi vývojáři a klientem. V dnešní době je základem dobře připravený plán, ve kterém klient musí dobře rozumět, co budou vývojáři dělat a vývojáři musí vědět, co klient přesně chce. Řešením je zorganizovat proces vývoje tak, aby mu analytici, klienti, programátoři a ostatní osoby, které se účastní vývoje systému, dokázali porozumět a souhlasili s ním. Takovou organizaci a uspořádání zajišťuje jazyk UML. UML (Unified Modeling Language) je výsledkem práce analytiků a designerů, kteří v průběhu 80. a 90. let vytvářeli metody umožňující popsat objektově orientovanou analýzu a návrh. První verze modelovacího jazyka UML vznikla v roce 1997 a dnes je jedním z nejpoužívanějších a nejperspektivnějších nástrojů ve světě vývoje systému. Jazyk UML umožňuje systémovým vývojářům standardně a srozumitelně zachytit představy o systému a zprostředkovat je dalším osobám. (Kanisová, 2006) Aktuálně používaná verze 2.0 obsahuje tři skupiny diagramů. První skupinou jsou strukturní diagramy popisující statické chování systému, mezi tyto diagramy můžeme řadit:  diagram tříd  diagram komponent  diagram nasazení  diagram balíčků Další skupinou jsou diagramy chování popisující dynamickou strukturu systému, jmenovitě:

16

Objektová analýza

 diagram aktivit  diagram případu užití  stavový diagram Poslední skupina, diagramy interakce, obsahuje tyto diagramy:  sekvenční diagram  diagram komunikace  diagram časování Zvýrazněné diagramy byly použity při tvorbě návrhu a jsou popsány v další části práce. 3.1.1

Diagram případu užití

Již dlouhou dobu se vývojáři snaží modelovat všechny typické interakce uživatele se systémem. Cílem tohoto snažení je, aby vývojáři lépe pochopili skutečné požadavky uživatelů a aby mohl být přesně vymezen rozsah budoucí aplikace. A právě případy užití zachycují funkčnost, která bude výsledným informačním systémem pokryta. Každý případ užití popisuje jeden ze způsobů použití systému a dohromady tvoří diagram případů použití. Diagram případů užití si můžeme představit jako soubor scénářů pro používání systému. Každý scénář popisuje posloupnost (sekvenci) událostí. Každou sekvenci inicializuje osoba, jiný systém, část hardwaru nebo uplynutí jistého času. Osoby, které sekvenci inicializují, se nazývají aktéři. Události, které jsou výsledkem sekvence, se nazývají případy užití. Jednotlivé případy užití jsou součástí systému, který je omezen hranicí systému. Mezi aktéry a jednotlivým případy užití existují vazby, tyto vazby mohou existovat i mezi jednotlivými případy užití. Aktér je jakýkoliv externí objekt, který komunikuje, tj. vyměňuje si informace, se systémem. Všechny akce v systému jsou vyvolány právě těmito aktéry. Pohled na případy užití očima aktérů nám může usnadnit nalezení případu užití. V některých systémech může být obtížné identifikovat kompletní seznam případů užití, a proto je lépe nejprve definovat všechny aktéry a následně pro každého z nich najít příslušný případ užití. Ačkoliv je pro znázornění aktérů v jazyce UML zaveden symbol postavičky, nejsou těmito aktéry vždy lidé. Jako aktér může vystupovat externí systém, který potřebuje informace z našeho systému, ale dokonce i čas. Čas jako aktér se používá v situacích, kdy se v určitou hodinu spouští v systému pravidelné zpracování bez zásahu obsluhy. Takovouto situací může být pravidelné zálohování dat nebo denní uzávěrka. Při identifikaci aktérů na konkrétním projektu se často setkáváme se situací, kdy nalezneme několik aktérů, kteří spouštějí stejné případy užití a liší se pouze tím, že někteří spouští další případy užití. V takovém je vhodné použít generalizaci aktérů, která usnadňuje modelování vazeb mezi aktéry a případy užití. Pro definici případu užití je nutné se nejprve seznámit se scénářem případu užití. Scénář je sekvence kroků popisujících interakci mezi aktérem a systémem.

Objektová analýza

17

Dobře napsaný scénář ne náhodou připomíná skutečný scénář např. divadelních her, ve kterém je v každém kroku poznat, kdo zastupuje jakou roli a jakou vykonává akci. Případ užití je tedy sada scénářů, které spojuje dohromady společný cíl. Tento případ užití je vždy iniciován aktérem a vyjadřuje, co budoucí systém nabídne uživateli. Případy užití reprezentují vždy jen vnější pohled na systém. V praxi převládá pravidlo, že případ užití má výchozí scénář, který je typu „všechno jde hladce“ a několik dalších scénářů popisující alternativní cesty, které popisují postup při zjištění různých chyb nebo mimořádných stavů. Každý případ užití by měl mít konkrétní popis, aby se předešlo nejasnostem. Při vytváření popisu je vhodné dodržovat jednotný slovník pro všechny použité termíny. Další upřesnění případu užití je možné pomocí takzvaných vstupních a výstupních podmínek. Ty definují podmínky, za kterých je možné případ užití zahájit a kritéria, které musí být splněna po skončení případu užití. V jazyce UML je případ užití zobrazován jako elipsa, ve které je zanesen jeho název. (Kanisová, 2006) Kromě vztahů mezi případy užití a aktéry existuje také několik druhů vztahů mezi samotnými případy užití. Jedná se o vztahy:  relace <>  generalizace případů užití  relace <<extend>> Relace <> se objevuje tam, kde existuje stejná nebo podobná část sekvence scénáře, opakující se ve více případech užití. Jinak řečeno, jedná se o vyčlenění společného chování ze scénářů základních případů užití. Důležité je, že základní případ užití, není bez rozšiřujícího případu užití kompletní a nelze provést. Zobecnění (generalizace) případů užití umožňuje převést společné chování více případů užití do rodičovského případu užití. Tato technika, ale není příliš doporučována, protože zvyšuje nepřehlednost modelu případu užití. Relace <<extend>> přidává nové, rozšiřující chování do základního případu užití. Podstatným rozdílem oproti relaci <> je fakt, že základní případ užití je bez rozšiřujícího případu sám o sobě soběstačný a použitelný. K základnímu scénáři přidává tzv. body rozšíření (extension points), které nejsou součástí scénáře, ale pouze poukazují na místo ve scénáři, kde může být funkčnost rozšířena. Případ užití může mít více bodů rozšíření a rozšiřující případ užití může rozšiřovat jeden nebo více těchto bodů rozšíření. Všechny tyto vazby se v jazyce UML znázorňují čárkovanou čárou mezi danými případy užití. (Kanisová, 2006) 3.1.2

Diagram tříd

Při návrhu objektově orientovaných systémů se modelují šablony pro vytvoření tříd objektů. Každá třída je jednoznačně určena svými atributy a operacemi. Při návrhu třídy určujeme pouze název a typ atributy. Atributům se přiřazují skutečné hodnoty až při vzniku instance objektu.

18

Objektová analýza

Atributy třídy jsou nositeli informací a jsou definovány svým názvem, datovým typem a viditelností. Viditelnost je charakteristika, která určuje atributům možnosti přístupu. V UML rozlišujeme tři základní typy:  Public. Označuje veřejný přístup, to znamená, že kterýkoliv element systému může k těmto atributům přistupovat.  Private. Označuje soukromý přístup. K atributům mají přístup pouze operace implementované v dané třídě.  Protected. Označuje chráněny přístup. K atributům mohou přistupovat pouze operace implementované v dané třídě a v jejich potomcích. Kromě atributů obsahují třídy také operace. Ty popisují její chování a mají také svou charakteristiku, která obsahuje název, viditelnost, argumenty a návratový datový typ operace. Diagramy tříd zobrazují statickou strukturu systému, především vztahy mezi třídami. Vztahy, které jednotlivé třídy navzájem pojí, jsou asociace, agregace, kompozice a specializace/generalizace. Podřízenost jednoho objektu vůči druhému je v analýze chápána buď jako agregace, nebo jako kompozice. Jednou z nejčastějších vazeb modelování tříd je agregace. Agregace vyjadřuje, že jedna třída je částí druhé třídy. Příklad této vazby je třída Auto a třída Motor. Kompozice je pouze speciální typem agregace, ve které podřízený objekt nemůže existovat bez nadřízeného objektu. Posledním typem vazby je asociace. Ta znázorňuje vztah mezi jednou či více třídami, které mezi sebou mají přímý vztah. (Kanisová, 2006)

3.2

Diagram entit

Při tvorbě datového modelu rozdělujeme pohled na data na logický a fyzický datový model. Logický datový model je nezávislý na implementaci, naproti tomu fyzický model již zvolenou relační databázi zohledňuje. Logický datový model je znázorněn pomocí diagramu entit. (Kanisová, 2006) Diagram entit obsahuje několik elementů. Mezi tyto elementy řadíme:  Entita. Abstraktní datový objekt, který seskupuje určitá data.  Atribut. Položky dané entity. Atributy jsou určeny svým formátem (datovým typem) a velikostí.  Vazba. Vazba jasně určuje vztah mezi entitami. Existují tři typy vazeb a to vazba 1:1, 1:N a M:N.  Klíč. Klíč je významný atribut, který může vyjadřovat jednoznačnost (primary key), unikátnost (unique key) nebo propojení s jinou entitou (foreign key).

Použité jazykové prostředky

19

4 Použité jazykové prostředky 4.1 4.1.1

ASP.NET Představení

Jedná se o relativně novou generaci technologií od firmy Microsoft, která slouží k vytváření webových aplikací. Je jednou z nejdůležitějších součástí .NET Frameworku, který soustřeďuje skupinu technologií do platformy nabízející kompletní řešení pro vývoj nejen webových, ale i desktopových aplikací pro operační systém Windows. 4.1.2

.NET Framework

Framework .NET skýtá ohromnou kolekci funkcionality, která je seskupena do logicky uspořádaného a hierarchicky seřazeného kontejneru, nazvaného jmenný prostor (namespace). Každý jmenný prostor poskytuje různé funkce a dohromady poskytují funkcionalitu pro téměř jakýkoliv aspekt distribuovaného vývoje. Tato velká skupina nástrojů se označuje termínem knihovna tříd (class library). Třídy Frameworku .NET používáme v ASP.NET stejným způsobem jako v jakémkoliv jiném druhu aplikace .NET. Navzdory tomu, že každý druh aplikace má své specifické zákonitosti, většina jmenných prostorů .NET Frameworku je společná pro všechny typy aplikací. Příkladem společného jmenného prostoru může být přístup k databázím nebo vícevláknové programovaní. Kromě součásti ASP.NET obsahuje .NET Framework další technologii pro vývoj webových služeb a komunikační infrastruktury aplikací (WCF), technologii pro vytváření efektních uživatelských rozhraní (WPF) a také podporuje implementaci jazyka LINQ, který slouží pro objektový přístup k datům v databází a dalších objektech. (MacDonald, 2008) 4.1.3

Kompilace, vícejazyčnost a CLR

Vývoj pomocí technologie ASP.NET není omezen na jeden programovací jazyk, ale umožňuje používat všechny jazyky podporující CLR (Common Language Runtime) jako jsou například Visual Basic .NET, JScript .NET nebo mnou preferovaný C#. Tento princip je umožněn tím, že se všechny aplikace ASP.NET vždy kompilují, a to ve dvou etapách. V první etapě se kód napsaný v jakémkoliv z výše uvedených jazyků zkompiluje do přechodného jazyka, který se nazývá Microsoft Intermediate Language (MSIL nebo jen IL). Výsledný kód je téměř identický bez závislosti na původním jazyce. Zkompilovanému souboru s kódem se říká assembly. Druhá etapa nastává těsně před vykonáním stránky. V tomto okamžiku se kód v IL zkompiluje do nativního, nízko úrovňového strojového kódu. Tato kompilace nese označení just-in-time (JIT) a probíhá stejně jak pro webové tak i desktopové aplikace .NET. Vizualizaci tohoto kompilačního procesu vidíme na následujícím obrázku.

20


Obr. 1 Kompilace webové stránky ASP.NET Zdroj: ASP.NET 4 a C# 2010: Tvorba dynamických stránek profesionálně

Kompilace JIT by nebyla tak užitečná, kdyby se musela provádět pokaždé při zobrazení webové stránky. Nový kód IL se vytvoří pouze tehdy, dojde-li ke změně ve zdroji. Patrně nejdůležitějším prvkem enginu ASP.NET je to, že běží uvnitř prostředí Common Language Runtime. Využití tohoto prostředí poskytuje několik podstatných výhod, jak uvádí MacDonald, 2011 :  Automatická správa paměti a „svoz odpadků“ (garbage collection).  Typová bezpečnost.  Rozšiřovatelné metadata (dodatečné informace popisující kód).  Strukturované zpracování chyb.  Multithreading (fond vláken). 4.1.4

Webové formuláře a jiné vysokoúrovňové funkce

Klíčovou myšlenkou při vývoji pomocí ASP.NET je model navrhování webové stránky zvaný webové formuláře (web forms). Tento model je abstrakce, která modeluje stránku jako kombinaci objektů. Když prohlížeč požaduje konkrétní stránku, vytvoří se nejprve instance objektu stránky. Do tohoto objektu se poté vytvoří další objekty pro všechny ovládací prvky, které jsou uvnitř požadované stránky. Model webových formulářů používán od verze ASP.NET 1.0 je prakticky totožný s modelem v aktuální verzi ASP.NET 4.5. To je důkazem dobrého návrhu této technologie, díky které se mohli vývojáři zaměřit na přidávání mnoha dalších vysokoúrovňových funkcí, mezi které můžeme zařadit (MacDonald, 2011) :


21

 Vzory stránek. Tzv. master pages jsou opětovně využitelné šablony stránky, pomocí kterých lze jednoduše zařídit, aby každá stránka měla jednotný vzhled nebo obsahovala stejné záhlaví a zápatí.  Motivy. V originále themes slouží k nadefinování standardizované sady charakteristik vzhledu webových prvků.  Navigace. Tento nástroj umožňuje definování map webu, které popisují logické uspořádání stránek. Obsahuje také navigační prvky, jako jsou stromy nebo drobečkové navigace (breadcrumbs).  Bezpečnost a členství. Byly přidány funkce podporující ukládání přihlašovacích údajů uživatele (credentials), autentizace založená na rolích a předem vytvořené prvky obsluhující registraci a přihlášení uživatele.  Ovládací prvky pro zdroje dat. Pomocí těchto prvků lze přiřadit k jiným serverovým ovládacím prvkům data pro dynamické generování obsahu.  Web Parts. Umožňují zobrazit na jedné stránce různé informace pomocí oddělených panelů.  Profily. Tato funkce se stará o ukládání informací o jednotlivých uživatelích do databáze, bez nutnosti psaní databázového kódu. 4.1.5

Serverové ovládací prvky

Další důležitou vlastností technologie ASP.NET je objektově orientovaný model. Díky tomuto objektovému modelu máme z kódu přístup ke všem objektům v .NET Frameworku a můžeme těžit ze všech vlastností objektově orientovaného programovaní, jako je používaní rozhraní (interfaces) nebo rozšiřovaní tříd děděním. Typickou ukázku objektově orientovaného myšlení v ASP.NET můžeme nalézt u serverových ovládacích prvků (server-based controls). Serverové ovládací prvky jsou zapouzdřené objekty, ke kterým můžeme přistupovat z kódu a manipulovat s nimi (např. měnit vzhled, poskytnout nějaká data nebo reagovat na událost). Vývojáři nemusí psát ručně zdrojový kód jazyka HTML, protože jednotlivé objekty ovládacích prvků se do HTML převádí samy, těsně předtím, než webový server pošle stránku klientovi. Tyto prvky můžeme rozdělit na dvě kategorie:  Ovládací prvky HTML Jedná se o klasické statické fragmenty HTML, ke kterým je přidán atribut runat=“server“. Díky tomuto atributu se z nich stávají funkční ovládací prvky na straně serveru, ke kterým můžeme přistupovat a manipulovat s nimi ze zdrojového kódu. Můžeme zpracovávat jejich události, nastavovat jim atributy nebo vázat prvek na zdroj dat. Serverový ovládací prvek může vypadat třeba takto: Tento fragment značí ovládací prvek v podobě textového vstupního pole.

22


 Webové ovládací prvky Tyto prvky poskytují mnohem vyšší úroveň abstrakce a více funkcionality. Značky webových ovládacích prvků ASP.NET vždy začínají prefixem „asp:“ (zařazení do jmenného prostoru) a pokračují jménem třídy, který identifikuje název ovládacího prvku, který chceme vložit do stránky. Při načítání stránky se ASP.NET samo postará o převod ovládacích prvků a dle nastavení prohlížeče klienta zvolí správný fragment HTML, díky kterému proběhne korektní vykreslení. Příkladem webového ovládacího prvku je následující fragment, který vytvoří textové pole (HTML značka ) s textem „Ahoj světe“. U obou kategorií ovládacích prvků jsou povinné atributy ID a runat. První jmenovaný slouží k jednoznačnému identifikování prvku na stránce a druhý poskytuje frameworku informaci, že se jedná o serverový prvek. Rodina webových ovládacích prvků zahrnuje kromě jednoduchých (TextBox, Label, Button apod.), také komplikované prvky, které mohou ušetřit programátorovi spoustu práce s psaním kódu. Jedná se buďto o prvky, které slouží jako užitečné utility (Calendar, RequiredValidator) nebo o prvky, které se starají o zobrazování určitých informací ze zdrojů dat (GridView, TreeView). Tyto složité objekty mají naimplementovány někdy až desítky atributů, kterými lze upravit vše od vzhledu, řazení nebo stránkování výstupních dat až po funkcionalitu v případě vzniknu nebo zániku události. 4.1.6

Modely tvorby kódu a jejich vazby

Abychom mohli používat ovládací prvky, musíme je nejprve nějak dostat do webového formuláře. K tomu slouží dva modely vytváření kódu:  Přímý kód (incline code).  Kód v pozadí (code-behind). Přímý kód se podobá tradičnímu ASP, kde se veškerý kód a HTML ukládají do jediného souboru .aspx. Obslužný kód v některém jazyce .NET se píše do jednoho nebo více bloků označených tagem <script>, ve kterém můžeme reagovat na události ovládacích prvků a používat různé funkce. Naproti tomu, v případě kódu v pozadí, se každá webová stránka rozdělí do dvou soborů. Do souboru .aspx, ve kterém budou uloženy HTML značky a značky ovládacích prvků, a dále do souboru .cs, který bude obsahovat zdrojový kód stránky. Tento model nabízí mnohem lepší možnosti uspořádání, protože odděluje uživatelské rozhraní od programovací logiky, což je velmi smysluplné v situacích, kdy se vytvářené webové stránky začnou komplikovat a míchání zdrojového kódu a značek by vytvořilo nepřehledný, dlouhý kód. Používání modelu kódu v pozadí je všeobecně preferováno. (MacDonald, 2011) Propojení obslužného kódu s přímým kódem je zařízeno pomocí direktivy Page. Ta specifikuje jazyk stránky a říká ASP.NET, kde hledat přidružený soubor s kódem. Při kompilaci stránky se tímto propojením vygenerují členské proměnné


23

a díky parciálním třídám se sloučí s třídou naší stránky. Na příklad si vezmeme následující textové pole s názvem mujInput: Po kompilaci vznikne členská proměnná s modifikátorem viditelnosti: protected System.Web.UI.TextBox mujInput; Příznak protected značí, že se jedná o soukromou proměnnou, ke které mají přístup pouze potomci této třídy. System.Web.UI.TextBox jsou zřetězené názvy jmenných prostorů, do kterých tento ovládací prvek patří a mujInput je název prvku udaný atributem ID. Tato generace probíhá naprosto automaticky a nevědomky ji využíváme pokaždé, když z obslužného kódu čteme nebo nastavujeme hodnotu objektu mujInput. Zmíněné nastavení hodnoty probíhá následujícím způsobem: mujInput.Text = “Ahoj světe“; Tímto výrazem jsme do atributu Text, datového typu string, který je součástí objektu mujInput, přiřadili hodnotu „Ahoj světe“. 4.1.7

Obsluha událostí

K docílení interakce s uživatelem našeho webu je potřeba zpracovávat události, ke kterým dojde po uživatelském úkonu, jako je kliknutí na tlačítko. Toto zpracování probíhá uvnitř obsluh událostí (event handlers). Přidání obsluhy události probíhá ve dvou krocích. Prvním krokem je přidáním atributu OnNázevUdálosti (např. OnClick, OnCheckedChange, atd.) k ovládacímu prvku a nastavením jeho hodnoty na název metody, která obstarává danou funkcionalitu události. Druhým krokem je vytvoření právě této metody v obslužném kódu. Tato metoda musí mít nastaven modifikátor viditelnosti na protected, aby k ní mohl přímý kód přistoupit. V hlavičce funkce musí být dále uvedeny dva vstupní atributy, které funkce přejímá, a to atribut typu object a druhý atribut, který je typu EventArgs nebo některého odvozeného typu. Příklad tlačítka s nastavenou obsluhou události vidíme na následujícím řádku: Hlavička metody, která zpracuje tuto událost, potom vypadá takto: protected void tlacitko_Click(object sender, EventArgs e) Tato metoda splňuje všechny náležitosti, které byly řečeny výše - obsahuje modifikátor viditelnosti protected, a v hlavičce jsou definovány vstupní proměnné sender, typu object a proměnná e, typu EventArgs. Příznak void značí, že tato metoda nemá žádnou návratovou hodnotu.

24


Druhým způsobem, kterým lze ovládacím prvkům přiřadit obsluhu události, je prostřednictvím delegátů. Delegátů se využívá, vytváříme-li ovládací prvek dynamicky z obslužného kódu. Ukázka přidání delegátu v obslužném kódu: tlacitko.Click += tlacitko_Click; Tento zápis nám říká, že do atributu Click, který je typu Event Handler (obsluha události), přidáme metodu na jeho obsluhu. Tato metoda je identická s metodou použitou u prvního způsobu vytváření obsluh událostí. 4.1.8

Zpracování a životní cyklus stránky

Když už víme, jak ovládací prvky vložit do webového formuláře a nastavit jim obsluhu událostí, měli bychom si přiblížit, jak probíhá zpracování těchto událostí a celé webové stránky. Nejprve je třeba připomenout, že se webové aplikace vykonávají na serveru, nikoliv na klientovi. Uživatel sice provádí úkony ve svém prohlížeči, ale skutečné operace (jako je aktualizace dat v databázi) běží na vzdáleném webovém serveru. Předěl mezi klientem a serverem je zpracován technikou zvanou postback, kdy se stránka a veškeré informace dodané uživatelem, odešlou na server, kde se vykonají jisté akce. Jakmile ASP.NET obdrží takovou stránku, spustí odpovídající události na straně serveru. V HTML slouží k odeslání dat na server značka
, která po odeslání stránky, pomocí tlačítka s atributem Submit, shromáždí aktuální hodnoty ovládacích prvků a vloží je do jednoho řetězce. Ten se odešle na server prostřednictvím HTTP operace POST. V ASP.NET jsou všechny ovládací prvky umístěny uvnitř jediné značky , která má nastaven atribut runat=“server“, tím je zajištěno, že se po odeslání stránky nacházejí hodnoty všech prvků v jakémsi globálním poli, ke kterému můžeme přistupovat z obslužného kódu jakéhokoliv jazyka .NET (např. z C#). Díky tomu získáváme mnohem intuitivnější syntaxi kódu, který je navíc typově bezpečný. Například přiřazení aktuální hodnoty, zadané uživatelem ve výše definovaném prvku mujInput do nové proměnné typu string, docílíme pomocí tohoto kódu: string uzivatelskyText = mujInput.Text; Tento fragment kódu by se vyskytoval například v obsluze události tlačítka, nebo by mohl být součástí některé události, která se vykonává automaticky po každém odeslání stránky na server. Tyto události jsou součástí životního cyklu stránky ASP.NET a typickým příkladem hojně využívané události je Page.Load. Webový formulář se na serveru zpracovává postupně, po etapách. V každé etapě se vyvolají různé události. Hlavní etapy zpracování stránky ASP.NET jsou (MacDonald, 2011) :  Inicializace pracovního rámce stránky. Tady ASP.NET poprvé vytvoří stránku a vygeneruje do ní veškeré ovládací prvky, které jsme definovali po-


25

mocí značek ve webové stránce .aspx. V této etapě se odpálí událost Page.Init. Tu ovšem obsluhujeme jen zřídka, protože s velkou pravděpodobností nejsou objekty ovládacích prvků ještě úplně vytvořeny.  Inicializace uživatelského kódu. V této etapě zpracování se odpálí událost Page.Load, kterou zpracovává většina webových stránek. Provádí se zde veškeré požadované inicializace, konfigurace ovládacích prvků a podobně.  Validace. Novější verze ASP.NET obsahují ovládací prvky pro potřeby validace. Tyto prvky automaticky ověřují platnost hodnot jiných vstupních ovládacích prvků a v případě nutnosti zobrazují chybové zprávy. Validace probíhá po načtení ovládacích prvků, ale předtím než dojde k jiným událostem.  Obsluha událostí. Zde je stránka již plně načtena a byla provedena validace prvků. ASP.NET nyní proto může odpálit všechny události, ke kterým došlo od posledního odeslání webové stránky na server. Tato událost je typicky kliknutí na odesílací tlačítko.  Vázání dat. V této etapě se provedou aktualizace a dotazy proti zdroji dat, jako součást životního cyklu stránky. Událost, která se váže na tuto etapu, se nazývá Page.PreRender a je to poslední akce před tím, než se stránka převede do kódu HTML.  Úklid. Na konci životního cyklu se odpaluje událost Page.Unload a v tento okamžik přichází služba „svoz odpadků“ (garbage collection), která uvolňuje paměť zabíranou objekty, na které už se nebude potřeba odkazovat. Znázornění životního cyklu stránky vidíme na následujícím obrázku.

Obr. 2 Životní cyklus stránky ASP.NET Zdroj: ASP.NET 4 a C# 2010: Tvorba dynamických stránek profesionálně

26

4.1.9


Vývojové prostředí

Existuje několik možností jak vyvíjet webové aplikace pomocí ASP.NET. Můžeme psát zdrojový kód v libovolném textovém editoru, ale použití této techniky je velmi pošetilé. Firma Microsoft totiž vytvořila speciálně pro tvorbu aplikací v .NET vývojové prostředí Visual Studio. Program Visual Studio je profesionální vývojářský program, který obsahuje velké množství různých designerských nástrojů, perfektní sadu nástrojů pro ladění a v neposlední řadě nástroj IntelliSense, jež v reálném čase kontroluje syntaxi a nabízí všemožná doporučení, pomocí kterých lze ušetřit spoustu času při vývoji. Dalšími výhodami jsou předpřipravené sady testů, nebo absolutní podpora modelu kódu v pozadí, modelu master pages. Uživatelské rozhraní Visual Studia nabízí přesně takové utility, které programátor pro vývoj v ASP.NET potřebuje – pro tvorbu přímého kódu slouží grafické rozhraní Document, které umožňuje dokonce i drag-and-drop ovládacích prvků ze Sady nástrojů (Toolbox), pro přístup k databázím nabízí Průzkumníka serveru (Server Explorer), třídy jsou úhledně uspořádány v Zobrazení tříd (Class View) a chyby v kódu můžeme vidět v okně Seznam chyb (Error List). Vrcholem integrace ASP.NET do programu Visual Studio je zabudovaný vlastní webový server, na kterém je možné vyvíjené aplikace jednoduše spouštět, testovat a ladit.

4.2

Prezentační vrstva

Kromě výše zmíněných ovládacích prvků technologie ASP.NET bylo pro docílení přívětivého uživatelského rozhraní nutno použít dalších prvků jiných programovacích jazyků nebo technologií. V této kapitole budou představeny zásadní použité programovací jazyky a technologie. 4.2.1

HTML a CSS

Jazyk HTML vznikl na počátku 90. let minulého století v podobě stručného dokumentu obsahující popis několika elementů, používaných pro tvorbu webových stránek. Tyto elementy popisovaly odlišné části webových stránek, například záhlaví, odstavce a seznamy. Jak se jazyk HTML vyvíjel, přibývaly nové elementy a jazyk se přizpůsoboval novým potřebám. S každou verzí jazyka se měnilo číselné označení. Nejnovější verzí je HTML5. Jednou z důležitých vlastností návrhu jazyka HTML5 je zpětná kompatibilita se staršími verzemi a také skutečnost, že převážná část jazyka HTML5 funguje také ve starších prohlížečích. Verze 5 přináší podporu přehrávání zvukových souborů a videosouborů přímo z moderních webových prohlížečů, bez nutnosti instalace doplňků. (Castro, 2012) Kaskádové styly (Cascading Style Sheets) jsou kolekcí metod, které jsou používány pro popis grafického zobrazení webové stránky. Nejčastější použití se objevuje u HTML a XHTML, ale tento jazyk může být použit na jakýkoliv XML dokument.


27

CSS bylo primárně vytvořeno, aby vývojářům umožnilo oddělení formy od obsahu stránky. Pomocí CSS lze nastavovat barvy, písmo, pozice a velikosti prvků, dekorační prvky, odsazení, mezery a mnoho dalších věcí. Aktuální verzí jazyka CSS je verze CSS3, která umožňuje některé nadstandartní efekty, jako jsou zaoblené rohy nebo přechody. 4.2.2

JavaScript

Příjemné uživatelské rozhraní je pro uživatele sytému jedna z nejdůležitějších věcí, a ač se dá vytvořit pouze s využitím HTML a CSS, velká většina dnešních webů používá dalších prostředků ke zlepšení uživatelského komfortu. Jedním takovým prostředkem je programovací jazyk JavaScript. JavaScript je multiplatformní, moderní interpretovaný jazyk, jehož autorem je Brendan Eich. Původně byl JavaScript navržen jako objektově orientovaný jazyk, avšak jak se postupně rozvíjel, programátoři jiných programovacích jazyků (jako je Ruby, Python a Perl) začali do jazyka prosazovat své programátorské názory (Resig, 2007). Syntaxe JavaScriptu patří do rodiny jazyků C/C++/Java, avšak s jazykem Java jej spojuje pouze podobná syntaxe, jinak se jedná především o marketingový tah. JavaScript se používá při programování webových stránek a aplikací jako doplněk k jazyku HTML, který umožnuje obohatit statické stránky o dynamicky generovaný obsah. Jádro jazyka JavaScript je součástí všech moderních webových prohlížečů a obvykle se spouští až po stažení webové stránky z internetu, proto mluvíme o tzv. skriptování na straně klienta (tzn. JavaScript je vykonáván webovým prohlížečem uživatele) na rozdíl od jazyků PHP nebo ASP, které jsou vykonávány na straně serveru, ještě před stažením stránky z internetu. Dynamické měnění obsahu stránky je realizováno prostřednictvím přístupu k objektovému modelu dokumentu (angl. Document Object Model – DOM), což je objektově orientovaná reprezentace XML nebo HTML dokumentu. DOM představuje rozhraní umožňující modifikaci obsahu, struktury nebo stylu dokumentu, popřípadě jeho částí. DOM reprezentuje dokument jako strom, ve kterém jsou jeho uzly jednotlivé elementy HTML stránky. Ukázku stromové struktury DOM modelu vidíme na následujícím obrázku.

28

Obr. 3


Ukázka stromové struktury HTML dokumentu pomocí DOM

Prostřednictvím JavaScriptu potom přistupujeme k uzlům a měníme jejich obsah. Jednotlivé uzly můžeme také přidávat nebo odebírat. Přístup k uzlům se provádí pomocí základních funkcí jazyka JavaScript (jmenovitě getElementByID a getElementsByName), volaných na kořenový uzel DOM modelu – vlastní HTML dokument stažený ze serveru. Tyto funkce vrací pole uzlů, na kterých je možné provádět traverzovaní (tj. přesun ve stromové struktuře) nebo modifikaci pomocí předdefinovaných funkcí jazyka. Jiným typickým příkladem použití JavaScriptu je kontrola správnosti vyplnění (tzv. validace) formuláře před odesláním na server, vytvoření rozbalovacího navigačního menu nebo obrázky, které se změní, když nad nimi přejedeme kurzorem myši. V minulých letech se objevilo ještě jedno významné využití JavaScriptu v technologii vývoje interaktivních webových aplikací zvané AJAX (Asynchronous JavaScript and XML). O technologii AJAX blíže pojednává jedna z dalších kapitol této práce. Důležitou vlastností JavaScriptu je, že má volně přístupnou dokumentaci, která je nutným základem pro tvorbu rozšíření pro tento jazyk. Tyto rozšíření v podobě knihoven mohou velmi zjednodušit práci s JavaScriptem a právě díky nim se v dnešní době těší JavaScript takové oblibě. S jednou z nejznámějších a nejoblíbenějších knihoven se seznámíme v další části práce. 4.2.3

AJAX

Tento akronym slov Asynchronous JavaScript and XML je skupina vzájemně souvisejících technik vývoje webu používaných na straně klienta, která se využívá při tvorbě asynchronních webových aplikací. Co vlastně znamená asynchronní webové aplikace? To jsou takové aplikace, ve kterých při výměně dat prohlížeče se serverem nedochází k překreslování stránky. Tato výměna dat probíhá nepozorovaně v pozadí, a pokud si vývojář aplikace nepřeje jinak, uživatel si této výměny ani nevšimne. Probíhá odděleně - asynchronně s ostatními akcemi na stránce.


29

Jazyk JavaScript spojuje všechny použité technologie a využívá rozhraní XMLHttpRequest pro komunikaci se serverem prostřednictvím protokolu HTTP. Server zpracuje požadavek a pošle na prohlížeč klienta odpověď. V této odpovědi můžeme zjistit, jestli se požadavek podařilo zpracovat (odpověď obsahuje stavový kód) a v případě úspěchu především získat data, které jsme požadovali. Tyto data poté JavaScript prostřednictvím modifikace DOM modelu zakomponuje do stránky (Resig, 2007). Již z překladu vyplývá, že se jedná o technologii pro asynchronní výměnu dat s webovým serverem prostřednictvím jazyka JavaScript a technologie XML. V dnešní době už je ale „X“ v názvu trošku zavádějící, protože použití technologie XML není nutnou podmínkou a je možno místo toho použít jiný formát dat jako je třeba JSON, prostý text nebo HTML. Vytvoření asynchronního požadavku nepatří mezi triviální záležitosti a je k tomu potřeba jisté množství znalostí. Používání této techniky vyžaduje spojení několika technologií a je potřeba myslet na ošetření všech stavů odpovědi serveru. Naštěstí vývojáři některých JavaScriptových knihoven mysleli i na techniku AJAX a velmi zpříjemnili její používání. (Lacko, 2008) 4.2.4

Knihovna jQuery

Formální definice knihovny říká, že: „jQuery je knihovna s otevřeným zdrojovým kódem určená pro jazyk JavaScript, která zjednodušuje interakci mezi dokumentem HTML, přesněji řečeno objektovým modelem dokumentu (model DOM), a jazykem JavaScript“ (jQuery kuchařka programátora, 2010). Kromě všech těchto výhod je jQuery open source knihovna, která podléhá licencím MIT a GNU General Public Licence. Díky těmto licencím je v mnoha směrech volně k dispozici – každý si ji může bezplatně stáhnout a používat. Tato knihovna je navíc i otevřeně vyvíjena, to znamená, že kdokoliv může opravovat chyby, vylepšovat ji a pomáhat s jejím vývojem. Již definice knihovny nám naznačuje, že obsahuje velké množství funkcí, které velmi znatelně ulehčí procházení a manipulaci s dokumenty HTML, zpracování událostí prohlížeče, animace nad modelem DOM nebo interakci prostřednictvím technologie AJAX. Právě na zjednodušeném používání techniky AJAX, při kterém se jQuery samo postará o provedení asynchronního HTTP požadavku, je krásně vidět filozofie této knihovny, kterou nejlépe vystihuje věta: „Pište méně, dělejte více.“ Tuto filozofii lze rozdělit na tři části (jQuery kuchařka programátora, 2010) :  Hledání elementů (pomocí selektorů jazyka CSS) a manipulace s nimi (prostřednictvím metod knihovny jQuery).  Řetězená volání metod jQuery na skupině elementů.  Používání obalu jQuery a implicitní iterace. Pochopit podrobně tyto tři principy je nezbytné, ale po jejich zvládnutí nás knihovna odmění znatelnou úsporou času a menším množstvím napsaného kódu.

30


4.3 4.3.1

Aplikační vrstva C#

Jazyk C# a související prostředí .NET Framework je jednou z nejdůležitějších technologií pro vývojáře během posledních let. Návrh technologie .NET poskytuje prostředí, ve kterém lze vyvíjet téměř libovolné aplikace určené pro sytém Windows, zatímco C# je nový programovací jazyk, který byl navržen zejména pro spolupráci s technologií .NET. Pomocí jazyka C# je možné vytvořit dynamickou webovou aplikaci, webovou službu XML, komponentu distribuované aplikace, klasickou desktopovou aplikaci a mnoho dalších. C# je vysokoúrovňový, striktně objektově orientovaný programovací jazyk, který je nepřímým potomkem jazyku C, se kterým sdílí část syntaxe. Firma Microsoft postavila základy jazyka C# na jazycích C++ a Java. Je také důležité podotknout, že tento programovací jazyk úspěšně splňuje standardy komise ECMA. (Evjen, 2009) Nejdůležitější vlastností tohoto jazyka je jeho čistě objektový návrh. Jakýkoliv kód musí být součástí některé třídy. Z této koncepce potom vyplývají vlastnosti, jako je zapouzdření, abstrakce, dědičnost, polymorfismus nebo neexistence globálních proměnných. Přehled všech hlavních charakteristik jazyka C# je uveden zde:  má vysokou typovou bezpečnost  není nutná dopředná deklarace  je case-sensitive  nepodporuje vícenásobnou dědičnost  třídy mohou implementovat více rozhraní  nemá globální proměnné a metody  všechny atributy a metody jsou deklarovány uvnitř těla třídy  podporuje statické metody a proměnné veřejných tříd  umožňuje používat Property – atributy s metodami get a set Zajímavostí je vznik názvu tohoto jazyka. Jedná se o symboliku s hudební notací, ve které křížek označuje zvýšení noty o půl tónu, tedy že C# je zlepšený jazyk C.


31

5 Analýza současného stavu 5.1

Popis organizace

Dům dětí a mládeže Tišnov je příspěvkovou organizací Města Tišnova, která vykonává činnost školského zařízení pro zájmové vzdělávání. Tato příspěvková organizace má sídlo v Tišnově na ulici Riegrova 312. Založena dne 1. 9. 1999. Činnost organizace DDM je určena pro děti, žáky, studenty, pedagogické pracovníky, popřípadě jiné další osoby, a to bez ohledu na místo jejich trvalého pobytu nebo jiné podmínky. Organizace provozuje činnost po celý školní rok, a to i ve dnech, kdy neprobíhá školní vyučování. Činnost střediska se uskutečňuje ve více oblastech zájmového vzdělávání a to zejména těmito formami:  pravidelná výchovná, vzdělávací a zájmová činnost  příležitostná výchovná, vzdělávací, zájmová a tematická rekreační činnost  táborová činnost  osvětová činnost  spontánní činnost Počty účastníku v jednotlivých činnostech jsou zobrazeny v následující tabulce. Tab. 1

Počty účastníku k 31. 10. 2012

Činnost Pravidelná zájmová činnost Příležitostná zájmová činnost Táborová činnost a pobytové akce Osvětová činnost (kurzy, workshopy) Spontánní činnost

Počet účastníků 716 2844 354 197 60

Zdroj: Koncepce rozvoje DDM Tišnov 2012-2018

Činnost kroužků probíhá pravidelně jednou až dvakrát týdně. Nabídka kroužků reaguje na aktuální zájmy dětí i rodičů. Kroužky jsou dle zaměření rozdělené do pěti oddělení. Jedná se o výtvarné, sportovní, počítačové, přírodovědné a duhové (dramatika, angličtina, herní klub) oddělení. Příležitostná zájmová činnost představuje jednorázové akce nejenom pro děti, ale i pro nejširší veřejnost. Tyto akce probíhají během celého školního roku, a to zejména o víkendech. Další oblastí činnosti DDM je organizování vzdělávacích i rekreačních kurzů pro mládež i dospělé. Jedná se především o kurzy výpočetní techniky a rukodělné kurzy, navazující na tradiční řemesla a umění. Prázdninové aktivity jsou velkou částí náplně DDM. Jsou pořádány během hlavních i vedlejších školních prázdnin.

32


5.2

Model informačního systému DDM

5.2.1

Specifikace požadavků

Prostřednictvím komunikace s vedením organizace DDM Tišnov byla vytvořena specifikace konkrétních požadavků, které by měl výsledný informační systém být schopen řešit. Na základě požadavků byl poté vytvořen diagram případů užití. 1.

Funkční požadavky:  Členové mohou vyplnit elektronickou přihlášku a tím provést registraci do některé z činností DDM.  Členové získají registrací přihlašovací údaje do informačního systému, kde mohou zjistit informace o stavu svých přihlášek a přihlášky spravovat.  Lektoři se přihlašují do informačního systému na základě přihlašovacích údajů, získaných od administrátora informačního systému.  Lektoři mohou v informačním systému provádět akce s přihláškami členů těch činností, ke kterým mají udělené oprávnění.  Lektoři mohou v informačním systému prohlížet detailní informace o všech členech.  Lektoři mohou spravovat svoje přihlašovací údaje.  Lektoři evidují docházku v činnostech, za které odpovídají.  Lektoři zanášejí přijaté platby k jednotlivým přihláškám.  Lektoři zanášejí fyzicky přijaté přihlášky do informačního systému.  Administrátoři vytvářejí přihlašovací údaje lektorům.  Administrátoři spravují všechny činnosti evidované v informačním systému.  Administrátoři spravují osobní údaje všech uživatelů informačního systému.  Administrátoři přiřazují lektory k činnostem.  Administrátoři mohou spravovat jakékoliv přihlášky.  Každý týden bude provedena záloha dat.

2.

Nefunkční požadavky:  Hesla uložená v databázi budou chráněna šifrováním.  Informační systém bude mít intuitivní uživatelské rozhraní.  Informační systém bude mít co nejnižší možné náklady na pořízení a provoz.  Informační systém bude mít co nejkratší dobu odezvy.  Při poruše nesmí dojít ke ztrátě dat.


5.2.2

33

Diagram případu užití

Tento diagram znázorňuje externí entity, které komunikují se systémem, a dává jasnou představu o akcích, které budou v tomto informačním systému probíhat.

Obr. 4

Diagram případu užití organizace DDM Tišnov

Při tvorbě diagramu případu užití bylo nutné nejprve definovat aktéry – entity, které budou komunikovat se systémem.  Účastník činnosti Tento aktér reprezentuje současného nebo budoucího člena libovolné činnosti provozované v DDM. Jedná se o uživatele informačního systému s nejmenšími možnostmi volby a nejnižší úrovní oprávnění. V informačním systému o něm evidujeme všechny informace, které jsou povinnými položkami u řádně vypl-

34


něné přihlášky. Kromě osobních údajů evidujeme také adresu, telefon, email (slouží pro přihlášení) a v případě potřeby také platební údaje.  Lektor Lektor reprezentuje jakéhokoliv zaměstnance DDM Tišnov, který pracuje s informačním systémem. Logicky disponuje větší úrovní oprávnění a provádí běžné akce v informačním systému. Lektoři jsou nejpočetnější skupinou uživatelů informačního systému. Evidujeme o nich stejné základní informace, jako o účastnících činností. Lektoři mají přiřazené činnosti a o jejich správu se starají. Většinou jsou to činnosti, které fyzicky vedou nebo se podílí na jejich chodu.  Admin Admin je specifický uživatel informačního systému, který disponuje téměř absolutními možnostmi voleb a dosahuje nejvyššího úrovně oprávnění. Typickým příkladem Admina je některý z pracovníků vrcholového managmentu (např. ředitel) nebo pracovník odpovědný za správu informačních technologií organizace.  Čas Aktér Čas znázorňuje časový interval, ve kterém dochází k automatickému provádění úkonů, ke kterým není potřeba žádného z výše uvedených uživatelů informačního systému. Po představení aktérů informačního systému můžeme podrobněji představit jednotlivé případy užití. V následujícím výčtu budou popsány pouze komplexnější případy užití.  Use Case Odeslání elektronické přihlášky Tento případ užití umožňuje aktérovi Účastník činnosti vyplnit a odeslat přihlášku k libovolné činnosti pořádané DDM. Aktér se může před vytvářením přihlášky přihlásit do informačního systému pomocí svých přihlašovacích údajů, díky čemuž se mu automaticky načtou jeho osobní údaje do přihlášky. Pokud provede odeslání přihlášky nepřihlášen a s jeho osobními údaji nebude nalezena shoda v databázi, vytvoří se mu uživatelský účet a na email mu budou poslány přihlašovací údaje. Díky generalizaci aktérů si mohou podat přihlášku do jakékoliv činnosti i aktéři Lektor popřípadě Admin.  Use Case Evidence účastníků Případ užití Evidence účastníků je jeden ze dvou klíčových procesů u aktéra Lektor. Po přihlášení do informačního systému získává Lektor možnost prohlížet si záznamy o účastnících libovolných činností DDM a díky rozšiřujícím případům užití také právo k editaci účastníka v jemu svěřené činnosti a možnost vytvoření nového člena. K tomuto procesu má přístup také aktér Admin.  Use Case Evidence přihlášek Druhým klíčovým případem užití je Evidence přihlášek. Po provedení autentizace je Lektor oprávněn prohlížet si evidenci všech přihlášek a za použití roz-


35

šiřujících procesů je schopen nad množinou svěřených uživatelů – tj. uživatelů navštěvující jemu svěřenou činnost, provádět operace jako jsou úprava přihlášky, zobrazení detailů přihlášky, přiřazení platby k přihlášce nebo vytvoření přihlášky do činnosti. Správu přihlášek může kromě Lektora provádět díky generalizace aktérů také Admin.  Use Case Vedení docházky v přiřazené činnosti U každé činnosti se eviduje docházka. Tento proces má na starosti Lektor. Každý lektor může evidovat docházku pouze v činnosti, ke které je přidělen Adminem.  Use Case Evidence uživatelů IS Tento proces, který je výlučně pro aktéra Admin, zajišťuje základní správu uživatelů informačního systému. Uživateli jsou v tomto kontextu myšleni jak běžní účastníci činností, tak lektoři, kteří z bezpečnostních důvodů nemohou měnit uživatelské údaje ostatním lektorům. Díky rozšiřujícím procesům má Admin možnost přidat, upravit nebo smazat uživatele informačního systému.  Use Case Evidence činností DDM Dalším klíčovým případem užití je proces, který má na starosti správu činností DDM. Evidence činností slouží k přehlednému znázornění poskytovaných činností, jako jsou pravidelné zájmové vzdělávání (kroužky), kurzy pro děti i dospělé nebo tábory. K těmto činnostem se poté mohou účastníci přihlašovat. U činností je evidována kapacita, cena a další informace, které se používají při procesu schvalování přihlášky.  Use Case Smazaní přihlášky Tento proces slouží k vyřazení přihlášky ze systému. Tato nevratná akce by mohla způsobit komplikace, když by byla provedena na nesprávné přihlášce, proto má právo na smazání pouze aktér Admin.  Use Case Přiřazení lektora k činnosti Admin má na starosti také přiřazování Lektorů k jednotlivým činnostem. Každá činnost musí mít nejméně jednoho Lektora, maximální počet není omezen. Pravidelné zájmové činnosti mají většinou právě jednoho Lektora, ale na nárazových akcích jako jsou tábory nebo karnevaly, apod. se podílí vždy více Lektorů.  Use Case Zálohování dat Na základě požadavků na systém bylo nastaveno pravidelné zálohování dat v intervalu jednou týdně. Toto zálohování probíhá automaticky na vzdálený server.

36

5.2.3


Diagram tříd

Statická struktura aplikace je popsána pomocí diagramu tříd, znázorněného na následujícím obrázku. Tento diagram tříd obsahuje 11 tříd včetně jejich atributů a metod.

Obr. 5

Diagram tříd organizace DDM Tišnov

Nejdůležitějšími jsou bezesporu třídy Uživatel, Přihláška a Činnost. Třída Uživatel obstarává registraci, přihlášení, přidání, úpravu údajů a smazání uživatele. Z této třídy jsou pomocí specializace odvozeny třídy Člen, Lektor a Admin, které mají své specifické atributy a metody. Třída Uživatel je přímo asociovaná s třídami Kontakt a Adresa. Třída Činnost je předkem tříd Kroužek a Akce, které reprezentují dlouhodobé a jednorázové činnosti DDM. Třída Přihláška slouží jako hlavní spojovací třídou mezi třídami Činnosti a Uživatel (respektive mezi jejich potomky) a je napojena na třídu Platba.


5.2.4

37

Entitně relační diagram systému

Na základě diagramu tříd z předchozí kapitoly byl navržen model databáze. Tento model bere základní třídy z diagramu tříd a tvoří z nich databázovou strukturu. Ukázku tohoto modelu vidíme na následujícím obrázku.

Obr. 6

ER diagram informačního systému DDM Tišnov

Tento diagram byl vygenerován pomocí nástroje Server Explorer vývojového prostředí Visual Studio, které bylo použito při vývoji webové aplikace. Kód použitý pro založení databáze a databáze se vzorovými daty se nachází na přiloženém DVD.

38

Návrh řešení

6 Návrh řešení 6.1

Rozvržení stránky

Grafický layout je řešen poměrně klasickým zobrazením, ve kterém jsou hlavní prvky vycentrované na prostředek stránky a poskládané pod sebou v pořadí: 1. Hlavička stránky 2.

Drobečková navigace

3. 4.

Primární navigace Hlavní okno stránky

5.

Patička

Barevné schéma bylo zvoleno vzhledem k barvám na logu organizace. Jedná se o barvy oranžová, modrá a zelená. Tyto barvy figurují v nadpisech, odkazech, u tlačítek a podobně. Zbytek stránky je laděn do bílo-šedého schématu, které je moderní, není zbytečně rušivé a působí elegantně. Šířka hlavních zobrazovacích prvků stránky byla zvolena kvůli správnému zobrazení 1218 pixelů. 6.1.1

Základní prvky stránky

Při tvorbě rozvržení stránky jsem využil funkci technologie ASP.NET zvanou master page. Jedná se o šablonu stránky, ve které jsou umístěny prvky jednotné pro všechny webové stránky, a do této šablony jsem umístil prvky:  Hlavička stránky. Tato hlavička obsahuje na levé straně logo, název webové aplikace a na pravé straně email aktuálně přihlášeného uživatele a odkazy sloužící pro přechod na stránku s uživatelským nastavením a pro odhlášení z informačního systému.

Obr. 7

Hlavička stránky

 Drobečková navigace. Pro doplňkovou navigaci byl zvolen tento typ navigace, protože nezabírá příliš místa na stránce a dobře informuje uživatele o jeho aktuálním umístění.

Obr. 8

Ukázka drobečkové navigace na stránce Detail přihlášky

Návrh řešení

39

 Primární navigační panel. Tento panel obsahuje tři hlavní položky navigace (Činnosti DDM, Evidence uživatelů a Evidence přihlášek) a jednu doplňující položku, která se mění v závislosti na aktuálně vybrané položce navigace a vždy zobrazuje možnost přidání nové entity (činnosti, člena, přihlášky). Aktuálně vybraná položka je barevně odlišená od ostatních položek. Barevné odlišení je použito i pro položku, nad kterou je právě přejížděno kurzorem myši. K tomuto odlišení byla zvolena jiná barva.

Obr. 9

Primární navigační panel

 Hlavní informační panel. Zde jsou zobrazovány nejpodstatnější informace webové aplikace. V případě evidenčních stránek je zobrazena tabulka, ve které jsou stylem „co řádek, to záznam“ uspořádány požadované informace. V případě stránek, které zobrazují detaily o jednom záznamu, jsou v tomto panelu přehledně uspořádány všechny dostupné informace.  Patička stránky. Slouží pouze k zobrazení statických informací o autorovi. 6.1.2

Doplňující prvky stránky

Hlavní prvky stránky jsou doplněny o nabídkový panel umístěný v levé části, který poskytuje uživateli volby v závislosti na aktuálně navštívené stránce. Příkladem voleb může být filtrace výsledků nebo skupina tlačítek pro editace, popřípadě smazání aktuálně prohlíženého záznamu. Ukázka filtrace záznamů je uvedena pod tímto textem.

Obr. 10

Filtrace činností na stránce Evidence činností

Druhým doplňujícím prvkem je informační panel nacházející se v pravé části stránky, který pomocí techniky AJAX po přejetí myší nad záznamem v evidenci, dynamicky zobrazuje užitečné informace o aktuálním záznamu.

Obr. 11

Informační panel zobrazující účastníky činnosti

40

6.2

Návrh řešení

Role a oprávnění uživatelů

Při návrhu webové aplikace hrálo stěžejní roli rozdělení oprávnění jednotlivých typů uživatelů informačního systému. Technologie ASP.NET poskytuje pro řešení uživatelských rolí a přihlašovaní vlastní techniky a postupy, které jsem se z důvodu prozatímní nedostatečné zkušenosti neodvážil použít. Vytvořil jsem si proto vlastní postup autentizace uživatele a rozlišení uživatelských rolí, který je založen na porovnávání aktuálně zadaných informací s daty z databáze. Výchozí formulář pro přihlašování obsahuje dvě textové pole, první pole je určeno pro email, druhé pro heslo. Pod tímto formulářem je umístěno tlačítko pro přihlášení. Ukázku přihlašovacího formuláře vidíme na následujícím obrázku.

Obr. 12

Přihlašovací formulář

Po stisknutí tlačítka se vykoná funkce, která přebírá jako parametry zadaný email a heslo. Toto heslo je kvůli bezpečnosti uložené v databázi v šifrovaném formátu pomocí algoritmu MD5. Přihlašovací funkce vrací booleovskou hodnotu pro kontrolu, zda zadané údaje odpovídají údajům v databázi a pokud údaje souhlasí, provede se přihlášení do systému. Po úspěšném přihlášení do informačního systému se do globálního pole zvaného Session uloží instance třídy Uživatel. Tato instance v konstruktoru načte z databáze konkrétního uživatele a pomocí doplňkových metod zjistí jeho roli v informačním systému. Na základě této role se na každé webové stránce vyhodnocuje podmínka, která zobrazuje nebo skrývá dané webové prvky. Kromě této podmínky se při každém načtení stránky také vyhodnocuje logický výraz, zda je konkrétní uživatel přihlášen. V případě, že není, proběhne přesměrování na přihlašovací stránku. Touto technikou je zabráněno neoprávněnému přístupu do systému.

Návrh řešení

6.3

41

E-přihláška

Každý uživatel informačního systému je oprávněn vyplnit a odeslat závaznou elektronickou přihlášku do libovolné činnosti DDM. Tato přihláška obsahuje všechny náležitosti klasické papírové přihlášky. Při přechodu na stránku s elektronickou přihláškou může dojít na dva scénáře:  Uživatel není přihlášen Elektronická přihláška je jediná webová stránka, na které není podmínka pro autorizovaný přístup. Je to z toho důvodu, že slouží i pro budoucí účastníky činnosti, kteří teprve chtějí vstoupit do některé činnosti. V případě, že na tuto stránku vstoupí nepřihlášený uživatel, zobrazí se mu několik nevyplněných textových polí, do kterých uživatel vepíše své osobní údaje, jako jsou jméno, příjmení, adresa, rodné číslo, email a telefon. Dále se na stránce nachází serverový ovládací prvek DropDownList, který slouží pro výběr činnosti, do které se chce uživatel přihlásit. Tento prvek je dynamicky načítán z databáze a obsahuje všechny činnosti evidované v informačním systému. Po vybrání určité činnosti se uživateli zobrazí informace o tom, kolik stojí členství a zda se z důvodu omezené kapacity ještě může přihlásit. Dále se také pomocí ovládacího prvku RadioButtonList zobrazí možnosti platby a po vybrání určitého způsobu platby, také doplňující informace. Při zmáčknutí tlačítka na odeslání přihlášky dojde k validaci (kontrole) zadaných hodnot a při úspěšném provedení této kontroly proběhne odeslání přihlášky do informačního systému. Při zpracování přihlášky v informačním systému dochází ke kontrole zadaných osobních údajů, a pokud se tyto údaje neshodují s žádným dosavadním uživatelem, dojde k automatickému vytvoření nového uživatele a na emailovou adresu zadanou na přihlášce, přijde informativní email o vytvoření účtu v informačním systému, který obsahuje automaticky vygenerované heslo, které je použito při přihlášení. Toto heslo si může každý uživatel po prvním přihlášení změnit.  Uživatel je přihlášen Pokud na tuto webovou stránku vstoupí přihlášený uživatel, načtou se jeho osobní údaje a automaticky se doplní do příslušných textových polí. Na uživateli potom zbývá už jen vybrat si požadovanou činnost a platební údaje. Zbytek procesu je stejný jako v případě neautorizovaného přístupu, s jediným rozdílem, že nedochází k vytvoření nového uživatele po odeslání přihlášky.

42

6.4 6.4.1

Návrh řešení

Činnosti DDM Evidence činností

Tato evidence slouží, jak už název napovídá, k zobrazování všech činností probíhajících v Domě dětí a mládeže. K vykreslení záznamů byl použit ovládací prvek technologie ASP.NET, zvaný ListView. Tento prvek, na základě předaného zdroje dat, automaticky generuje obsah do uživatelsky zadané šablony. Tato šablona byla nadefinována jako seznam záznamů, s prvky umístěnými pod sebou, ve kterém obsahuje jeden prvek několik řádků s informacemi. Každý záznam obsahuje informace o názvu a typu činnosti, místu, kde činnost probíhá, kapacitě, ceně a krátký popis činnosti. Součástí je také logo. Seznam činností je abecedně seřazen dle názvu činnosti. Ukázka evidence kroužků se nachází na následujícím obrázku:

Obr. 13

Webová stránka Evidence činnosti v DDM Tišnov

Ve výše uvedeném obrázku vidíme, že je právě zaplá filtrace a evidence vypisuje pouze činnosti typu kroužek. Na obrázku také vidíme, že je právě zvýrazněn kroužek Základy práce na PC. Toto zvýraznění se aktivuje v momentě, kdy se nad libovolným záznamem přejede kurzorem myši. V pravé části stránky vidíme doplňující informační panel zobrazující členy této zvýrazněné činnosti. Po kliknutí kamkoliv do zvýrazněného prostoru proběhne přesměrování na stránku obsahující detaily dané činnosti.

Analýza a návrh informačního systému příspěvkové organizace DDM Tišnov

6.4.2

43

Detail činnosti

Hlavní informační panel ve stránce s detailem činnosti je rozdělen na dvě části. V levé části najdeme základní informace o činnosti. V pravé části je uveden přehled členů činnosti s možností přidání účastníka pro tuto činnost. Přehled účastníků je řešen pomocí ovládacího prvku GridView, který zobrazuje data v mřížce, skládajících se z řádků a sloupců. Záznamy v tabulce je možno řadit podle libovolného sloupce po kliknutí na jeho hlavičku.

Obr. 14

Webová stránka Detail činnosti Základy práce na PC

Kromě možnosti přidání nového člena jsou na stránce vidět tlačítka pro úpravy a smazání této činnosti. Pokud k tomu má daný uživatel oprávnění, v pravé části stránky se zobrazí tlačítko pro přidání nové činnosti. Tyto funkce jsou dostupné pouze pro uživatele s rolí Admin.

44

6.4.3

Přidání člena do činnosti

Přidání člena do činnosti je řešeno pomocí modálního okna. Modální okno označuje techniku, ve které se na webovou stránku dynamicky přidá HTML element
, který má šířku a výšku přes celou stránku. Dále má tento prvek nastavený neutrální, jednobarevné pozadí a nastavenou určitou průhlednost. Tímto se vytvoří efekt překrytí původní stránky. Do daného prvku se poté vloží obsah, který budeme chtít pomocí modálního okna zobrazit. V tomto případě je to formulář pro přidání člena do činností. Tento formulář obsahuje prvek DropDownList, pro výběr ze stávajících členů a textová pole, pro vepsání údajů o novém členu. Formulář obsahuje také validátory, které neumožní přidat přihlášku bez správně vyplněných textových polí. Špatně vyplněné textové pole je označeno pomocí červeného textu s chybovou hláškou nacházející se pod konkrétním textovým polem. Modální okno s formulářem je znázorněno na dalším obrázku.

Obr. 15

Modální okno pro přidání člena do činnosti

Inicializace modálního okna je provedena pomocí ovládacího prvku ModulPopupExtender. Tento ovládací prvek není původní součástí ASP.NET, ale je součástí rozšíření AjaxControlToolkit. Tento nástroj umožňuje zjednodušenou práci s modálními okny a velmi usnadňuje používání techniky AJAX. Pro jeho začlenění do projektu bylo nutné přidat odkaz na stejnojmennou knihovnu a při používání uvádět, že se jedná o funkce ze jmenného prostoru AjaxControlToolkit.


6.5 6.5.1

45

Členové činností DDM Evidence členů

Hlavní panel poskytující informace o členech organizace je tvořen tabulkou, poskytující základní informace o každém členu. Záznamy v tabulce jsou graficky odlišeny pro zvýšení přehlednosti. Posledním sloupcem záznamu je element hypertextový odkaz, který slouží pro přechod na stránku s detaily o vybraném členovi. Obrázek, obsahující výřez stránky s evidencí členů, je uveden níže.

Obr. 16

Výřez webové stránky Evidence členů

Ovládacím prvkem, který generuje tuto tabulku je GridView, který poskytuje velké možnosti pro formátování. Řazení je možno provést kliknutím na nadpis jednotlivých sloupců, dle kterých chceme řadit. V levé části stránky je navigační panel obsahující prvky pro filtrování záznamů. Filtraci je možné provést dle zadaného jména, příjmení, adresy nebo emailu. V pravé části stránky se dynamicky zobrazuje doplňující informační panel, který informuje o přihláškách člena, přes kterého je právě přejížděno kurzorem myši. K docílení tohoto efektu je použito techniky AJAX a knihovny jQuery. Levá a pravá část stránky není na výše uvedeném výřezu zobrazena.

46

6.5.2

Detail člena DDM

Webová stránka Detail člena, zobrazuje velké množství informací o jednom konkrétním uživateli informačního systému. Kromě osobních, kontaktních údajů a adresy zde vidíme také přehled přihlášek tohoto člena a plateb spadajících pod tyto přihlášky. Ukázku stránky obsahující detail člena najdeme níže na této stránce. Údaje o členovi jsou zobrazeny pomocí ovládacího prvku DetailsView, který je určen pro poskytování detailů o jednom záznamu. Data jsou zobrazovány do uživatelsky definované šablony. DetailsView obsahuje šablony pro zobrazení, editaci a přidání nového prvku. Pomocí těchto šablon lze nadefinovat, jak budou informace zobrazeny v jednotlivých režimech zobrazení prvku DetailsView. Na tomto principu jsou postaveny funkce Úprav člena a Nový člen, kdy v zobrazovacím režimu jsou informace pouze vypsány do elementu a v editovacím režimu jsou převedeny do elementu , který slouží k úpravě textových polí. Na této stránce je také možné přidávat a odebírat přihlášky a platby pro tohoto člena. Přidání plateb a přihlášek probíhá pomocí modálních oken, tedy stejným způsobem, jako přidání člena do činnosti. K odebrání slouží tlačítko ve formě obrázku (červený křížek). Při přidávání platby je uživatel vyzván ke zvolení přihlášky, ke které daná platba patří. Platby a přihlášky jsou provázány pomocí variabilního symbolu, který odpovídá číslu přihlášky.

Obr. 17

Webová stránka obsahující Detail člena

Funkce na této stránce jsou opět zobrazeny pouze pro uživatele s příslušným zobrazením. Přidání platby a přihlášky je možné pro uživatele typu Lektor, ale například smazání přihlášky může provést pouze Admin.


6.6 6.6.1

47

Přihlášky DDM Evidence přihlášek

Webová stránka obsahující evidenci přihlášek byla tvořena téměř identickým způsobem jako Evidence členů. Opět byl použit prvek GridView, který obsahuje stejné formátování, jako ostatní evidence pro zachování jednotného grafického vzhledu. 6.6.2

Detail přihlášky

Tato část aplikace zobrazuje kompletní informace vztahující se k jedné konkrétní přihlášce a údaje o majiteli přihlášky. Hlavní ovládací prvek tvoří opět DetailsView, jako v případě Detailů člena. Formulář s detaily je navíc doplněn o panel sloužící k nahrání fyzického dokumentu přihlášky do systému. Ve formuláři jsou zvýrazněné nejdůležitější údaje v horní části hlavního okna. Stránku s detailem přihlášky vidíme na dalším obrázku:

Obr. 18

Webová stránka Detail přihlášky

V levé části obrazovky opět najdeme panel s možnostmi pro konkrétní přihlášku. Jedná se o přidání a úpravu plateb patřící k této přihlášce. Tyto volby jsou řešeny pomocí modálních oken, ve kterých je formulář pro zadání platebních podmínek. Formulář opět obsahuje validaci pro ošetření špatně zadaných vstupních hodnot.

48

7 Diskuze 7.1

Testování

První fází testování bylo naplnění aplikace daty. Veškeré testování probíhalo na fiktivních datech vytvořených na základě vzorku dat poskytnutých od pracovníků DDM. Tato varianta byla zvolena kvůli ochraně osobních údajů návštěvníků této organizace. Druhou fází bylo představení informačního systému zástupcům některých typů uživatelů a získání zpětné vazby ohledně použitelnosti uživatelského rozhrání a především vlastního systému. Především druhá fáze testování se ukázala jako velmi užitečná. Od uživatelů byly získány cenné poznatky, které byly použity pro úpravu rozložení ovládacích prvků za účelem zvýšení přehlednosti a použitelnosti informačního systému. První fáze proběhla bez komplikací, což naznačuje dobře zvolenou strukturu datových typů v databázi.

7.2

Ekonomické zhodnocení

Součástí nefunkčních požadavků na systém byl požadavek na co nejnižší možné náklady na pořízení a provoz. Vybral jsem dvě varianty pro provoz informačního systému, o kterých si myslím, že jsou finančně nejvýhodnější. Jedná se buďto o nákup vlastního serveru nebo o pronájem vzdáleného serveru. Pro analýzu nákladů v případě nákupu vlastního serveru byl vybrán nejprodávanější server na internetovém obchodě Alza.cz. Jedná se o serverový počítač Dell PE R210 1U, který stojí 26 090 Kč s DPH. Je popsán jako: „Kompletní, stabilní a moderní server formátu 1U jako výtečné řešení rozšíření i založení sítě pro malé podniky. Představuje ideální server se správnou kombinací poměru výkon/cena a síťového potenciálu.“ (Dell PE R210 1U, 2013). Důležitou vlastností je podpora operačního systému Windows Server, který je nutný k provozování aplikace vytvořené pomocí technologie ASP.NET. Operační systém Windows Server v edici Essentials, která je vhodná pro malé podniky, stojí v přepočtu 10 060 Kč s DPH (Windows Server 2012 R2, 2013). Databázový systém Microsoft SQL Server je v edici Express ke stažení zdarma. Pro pronájem serveru byla vybrána společnost Master Internet, která se zabývá mimo jiné pronájmem virtuálních serverů (Virtuální servery – VPS, 2013). Vzhledem k tomu, že se nepředpokládá mimořádně vysoký počet souběžně pracujících uživatelů informačního systému, organizaci by stačila základní varianta VPS Website za 320 Kč měsíčně. V této základní variantě, ale není zahrnuta služba zálohování dat, kterou organizace vyžaduje. Proto by bylo potřeba využít variantu VPS E-shop, která stojí 610 Kč měsíčně a kromě prostoru na zálohování nabízí také podstatně lepší hardwarové prostředky. K této ceně si ještě musíme přičíst přípla-


49

tek 120 Kč měsíčně za operační systém Windows Server, který si daná společnost účtuje. Tab. 2

Odhad nákladů na pořízení IS Produkt Serverový počítač Operační systém Náklady na 3 roky

Náklady na nákup 26 090 Kč 10 060 Kč 30 150 Kč

Náklady na pronájem 610 Kč / měsíc 120 Kč / měsíc 26 280 Kč

Morální životnost serveru se udává tři roky a z výše uvedené tabulky je jasně viditelné, že varianta s pronájmem je pro tuto životnost ekonomicky výhodnější. Varianta zahrnující nákup navíc nepočítá s doplňujícími náklady, jako jsou náklady na energie, zálohové napájení, problémy se zprovozněním serveru a eventuální náklady na opravu v případě poruchy. Vzhledem k tomu, že je DDM Tišnov příspěvková organizace, která hospodaří s vyrovnaným hospodářským výsledkem a nedisponuje finanční rezervou, by pro ni nákup serveru a s tím spojené další náklady znamenal velký, jednorázový výdej financí, který by si tato organizace nejspíše nemohla dovolit. Proto se jako lepší varianta jeví pronájem virtuálního serveru, který vyjde ekonomicky výhodněji a u kterého se náklady rozdělí do menších částí.

7.3

Možnosti rozšíření

Stávající verze informačního systému zpracovává jen část procesů, které probíhají v organizaci DDM. Aby se organizaci vyplatilo investovat do pořízení informačního systému, musel by tento systém umožňovat automatizaci všech hlavních procesů. Nejdůležitější chybějící částí systému je, dle mého názoru, modul agendy platů zaměstnanců, spojeny s přehledy celkových finančních toků organizace. Toto rozšíření by zahrnovalo nový typ uživatele Účetní, který měl přístup k různým finančním přehledům, statistikám a tiskovým sestavám. Tiskové sestavy by ušetřili práci např. se sestavováním zahajovacího výkazu nebo při účetní závěrce. Další možností rozšíření je zdokonalení systému docházek. Pokud by organizace získala dost finančních prostředků na nákup potřebné techniky pro všechny lektory, mohli by tito lektoři zadávat docházku v kroužcích přímo do informačního systému a nemusela by se evidovat papírová docházka v kroužcích. Pro tento účel by bylo vyhovující zařízení zvané handheld, přes které by měli lektoři přístup do informačního systému. Funkci handheldu by mohl zastoupit jakýkoliv levný tablet nebo smartphone.

50

8 Závěr Cílem této bakalářské práce bylo splnit úkoly stanovené v úvodní kapitole. Styčnými body k naplnění cíle bylo vytvoření analýzy datových toků příspěvkové organizace DDM Tišnov, návrh vhodného řešení a jeho implementace. Součástí řešení byla také jednoduchá ekonomická analýza nákladů spojených s eventuálním nasazením informačního systému. Pro splnění těchto úkolů bylo nutné nastudovat potřebný teoretický základ a zakomponovat ho do teoretické části práce. Nedílnou součástí práce byly konzultace se zaměstnanci DDM, které mi pomohly lépe pochopit některé procesy v organizaci, a které mi poskytly zpětnou vazbu ohledně vytvářené aplikace. Teoretická část bakalářské práce obsahuje dvě důležité kapitoly. První kapitola se věnuje objektové analýze, popisuje jazyk UML a rozebírá metodiky analýzy použité v praktické části práce. Druhá kapitola se zaobírá technologií ASP.NET a dalšími programovacími prostředky, které byly použity pro vlastní implementaci informačního systému. Praktická část práce nejprve představuje příspěvkovou organizaci DDM Tišnov, vyjmenovává funkční a nefunkční požadavky na systém a následně, pomocí diagramů jazyka UML, popisuje dynamickou a statickou strukturu budoucího systému. Další kapitola praktické části je věnována vývoji webové aplikace. Tato kapitola obsahuje popis technik použitých pro dosažení výsledků zobrazených na přiložených snímcích. V následné diskuzi jsou popsány techniky testování, rozebrány možnosti rozšíření a z ekonomického hlediska porovnány varianty nákupu a pronájmu serveru pro provoz této webové aplikace. Domnívám se, že předem stanovený cíl byl splněn. Webová aplikace byla vytvořena a organizaci byly představeny možnosti využití informačního systému, získala povědomí o jeho přínosech a záleží jen na vedoucích pracovnících, jestli budou chtít zapojit informační systém do provozu organizace.


51

9 Literatura CASTRO, ELIZABETH A BRUCE HYSLOP. HTML5 a CSS3: názorný průvodce tvorbou WWW stránek. 1. vyd. Brno: Computer Press, 2012, 439 s. ISBN 978-80-251-3733-8. Dell PE R210 1U. ALZA.CZ [online]. © 2000-2013 [cit. 2013-12-23]. Dostupné z: http://www.alza.cz/dell-pe-r210-1u-d332429.htm EVJEN, BILL. ASP.NET 3.5 v jazycích C# a Visual Basic: programujeme profesionálně. Vyd. 1. Brno: Computer Press, 2009, 1598 s. ISBN 978-80-251-2069-9. JQuery: kuchařka programátora. Vyd. 1. Brno: Computer Press, 2010, 436 s. ISBN 978-80-251-3152-7. KANISOVÁ, HANA A MIROSLAV MÜLLER. UML srozumitelně. 2. aktualiz. vyd. Brno: Computer Press, 2006, 176 s. ISBN 80-251-1083-4. LACKO, ĽUBOSLAV. Ajax: hotová řešení. Vyd. 1. Překlad Michal Brůha. Brno: Computer Press, 2008, 269 s. ISBN 978-80-251-2108-5. MACDONALD, MATTHEW A MARIO SZPUSZTA. ASP.NET 3.5 a C# 2008: tvorba dynamických stránek profesionálně. Vyd. 1. Brno: Zoner Press, 2008, 1584 s. ISBN 97880-7413-008-3. MACDONALD, MATTHEW, ADAM FREEMAN A MARIO SZPUSZTA. ASP.NET 4 a C# 2010: tvorba dynamických stránek profesionálně. Vyd. 1. Brno: Zoner Press, 2011, 1580 s. Encyklopedie Zoner Press. ISBN 978-80-7413-145-5. NAGEL, CHRISTIAN. C# 2008: programujeme profesionálně. Vyd. 1. Brno: Computer Press, 2009, 1898 s. ISBN 978-80-251-2401-7. RÁBOVÁ, IVANA. 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. RESIG, JOHN. JavaScript a Ajax: moderní programování webových aplikací. Vyd. 1. Překlad Ondřej Baše, Ondřej Žižka. Brno: Computer Press, 2007, 360 s. ISBN 978-80-251-1824-5. SCHMULLER, JOSEPH. Myslíme v jazyku UML. Vyd. 1. Praha: Grada, 2001, 360 s. ISBN 80-247-0029-8. SODOMKA, PETR A HANA KLČOVÁ. Informační systémy v podnikové praxi. 2. aktualiz. a rozš. vyd. Brno: Computer Press, 2010, 501 s. ISBN 978-80-251-2878-7. Virtuální servery - VPS. MASTER INTERNET [online]. © 1996-2013 [cit. 2013-12-23]. Prezentace produktů společnosti. Dostupné z: http://www.master.cz/virtualni-servery-vps/ Windows Server 2012 R2. MICROSOFT [online]. © 2013 [cit. 2013-12-23]. Dostupné z: http://www.microsoft.com/en-us/server-cloud/products/windowsserver-2012-r2/default.aspx#fbid=8pWxtptyRnL

52

Přílohy

Obsah přiloženého DVD

53

A Obsah přiloženého DVD  DDMTisnov.sql – soubor obsahující příkazy jazyka SQL pro založení databáze  ddm.mdf – databáze se vzorovými daty  DDMTisnov – složka obsahující všechny soubory a složky vytvořené při vývoji webové aplikace. Nejdůležitějším souborem je DDMTisnov.csproj, který uchovává všechny informace o projektu a pomocí nějž lze projekt otevřít v příslušném vývojovém prostředí.  packages – složka obsahující soubory nutné pro používání rozšiřujících nástrojů při vývoji

Analýza a návrh informačního systému příspěvkové organizace DDM Tišnov

Recommend Documents