VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky
Systém řízení odborných konferencí a seminářů bakalářská práce
Autor: Petr Fučík Vedoucí práce: Prof. RNDr. Milan Mišovič, CSc. Jihlava 2011
ANOTACE Tato bakalářská práce je zaměřena na řízení odborných konferencí a seminářů pomocí webové aplikace na Vysoké škole polytechnické v Jihlavě. Aplikace umoţňuje spravovat systém pomocí uţivatelů rozdělených do uţivatelských rolí. Uţivatelé se mohou registrovat na konference a díky struktuře aplikace přehledně spravovat své účty, vloţené příspěvky, či kontrolovat platby a podobně. Aplikace se dále snaţí co nejvíce ulehčit práci osobám, které se podílejí na pořádání konferencí. Jedním z pomocníků je schvalovací systém příspěvků, či návrhář programu konference. Dále aplikace nabízí vícejazyčný portál a další funkcionality. Aplikace je vytvořena na platformě .NET s vyuţitím vývojových nástrojů od společnosti Microsoft a navrţena podle objektového paradigmatu.
KLÍČOVÁ SLOVA .NET, řízení konferencí a semináře, webová aplikace, konference, semináře, vícejazyčnost, objektové paradigma
ABSTRACT This Bachelor Thesis is focused on control of special conferences and seminars by means of web application at the College of polytechnics in Jihlava. The application provides to control a system by means of users devided into user roles. The users can register themselves at conferences, and thanks to the application they can control their accounts, payments, or inserted contributions etc. Moreover, the application tries to simplify the users work. One of the assistants is an approving system of contributions, or a programme designer of conferences. Furthermore, the application offers a multilanguage portal and other functions. The application is made with the help of the Microsoft development tools on the .NET platform and designed according to the object-oriented paradigm.
KEYWORDS .NET, management conferences and seminars, web applications, conferences, seminars, multilanguage, object-oriented paradigm
PODĚKOVÁNÍ Rád bych poděkoval svému vedoucímu práce panu Prof. RNDr. Milanu Mišovičovi, CSc. za jeho odborné rady, informace a trpělivost při návrhu a zpracování této bakalářské práce.
PROHLÁŠENÍ Prohlašuji, ţe předloţená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, ţe citace pouţitých pramenů je úplná, ţe jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále téţ „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím uţitím k výuce nebo k vlastní vnitřní potřebě VŠPJ . Byl/a jsem seznámen/a s tím, ţe na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, ţe VŠPJ má právo na uzavření licenční smlouvy o uţití mé bakalářské práce a prohlašuji, ţe s o u h l a s í m s případným uţitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, ţe uţít své bakalářské práce či poskytnout licenci k jejímu vyuţití mohu jen se souhlasem VŠPJ, která má právo ode mne poţadovat přiměřený příspěvek na úhradu nákladů, vynaloţených vysokou školou na vytvoření díla (aţ do jejich skutečné výše), z výdělku dosaţeného v souvislosti s uţitím díla či poskytnutím licence. V Jihlavě dne 5.6.2011 ...................................................... Podpis
Obsah 1
Úvod.............................................................................................................................. 10
2
Vývojová prostředí ....................................................................................................... 12
3
4
2.1
MS Visual Studio 2010 Professional ..................................................................... 12
2.2
Microsoft SQL Server 2008 Express ..................................................................... 12
2.3
Adobe Photoshop CS3 Extended ........................................................................... 12
Vyuţité technologie ...................................................................................................... 13 3.1
ASP.NET................................................................................................................ 13
3.2
C# ........................................................................................................................... 13
3.3
CSS......................................................................................................................... 13
3.4
LINQ ...................................................................................................................... 13
3.5
JavaScript ............................................................................................................... 13
3.6
Ajax Control Toolkit .............................................................................................. 14
Analýza a návrh implementace ..................................................................................... 15 4.1
Porovnání s existujícím řešením ............................................................................ 15
4.2
Analýza modulů ..................................................................................................... 15
4.2.1
Portál ............................................................................................................... 16
4.2.2
Uţivatelé ......................................................................................................... 17
4.2.3
Role ................................................................................................................. 17
4.2.4
Menu ............................................................................................................... 19
4.2.5
Stránky ............................................................................................................ 21
4.2.6
Články ............................................................................................................. 23
4.2.7
Úvodní články ................................................................................................. 25
4.2.8
Konference ...................................................................................................... 26
4.2.9
Události ........................................................................................................... 26
4.2.10
Příspěvky ........................................................................................................ 27
4.2.11
Místa konání, budovy, místnosti ..................................................................... 28
4.2.12
Semináře ......................................................................................................... 29
4.2.13
Doprovodné akce ............................................................................................ 30
4.2.14
Výbory ............................................................................................................ 30
5
6
7
8
4.2.15
Ubytování, propagace města a školy .............................................................. 31
4.2.16
Platby/Účast .................................................................................................... 31
4.2.17
Zpravodaje ...................................................................................................... 32
4.2.18
Lokalizace ....................................................................................................... 33
Popis třívrstvé architektury aplikace ............................................................................. 38 5.1
Prezenční vrstva (presentation layer) ..................................................................... 39
5.2
Aplikační vrstva (business logic layer) .................................................................. 39
5.3
Datová vrstva (data access layer) ........................................................................... 40
Ovládací prvky .............................................................................................................. 41 6.1
CommandToolbar (lišta s příkazy)......................................................................... 41
6.2
Conference (přehled informací o konferenci) ........................................................ 42
6.3
FileUpload .............................................................................................................. 42
6.4
HTMLEditor .......................................................................................................... 43
6.5
Menu ...................................................................................................................... 44
6.6
PageControl ............................................................................................................ 44
6.7
PaymentAttendenceControl (Platba/Návštěvnost) ................................................. 45
6.8
PaymentAttandenceSeminarControl ...................................................................... 45
6.9
PostControl............................................................................................................. 45
6.10
SeminarControl (přehled informací o semináři) ................................................. 46
6.11
SiteMapControl (mapa stránek) ......................................................................... 46
6.12
SiteMapPath ....................................................................................................... 47
6.13
SponsorsToolbar ................................................................................................. 47
6.14
Time .................................................................................................................... 47
6.15
User..................................................................................................................... 47
Další funkce webové aplikace ...................................................................................... 49 7.1
Nastavení aplikace z konfiguračního souboru ....................................................... 49
7.2
Posílání e-mailů ...................................................................................................... 50
7.3
Zasílání chyb .......................................................................................................... 50
7.4
Zpravodaje.............................................................................................................. 50
Testování ....................................................................................................................... 51
9
Závěr ............................................................................................................................. 52 9.1
Zhodnocení práce ................................................................................................... 52
9.2
Moţnosti dalšího rozšíření aplikace ....................................................................... 53
Seznam pouţité literatury ..................................................................................................... 54 Seznam obrázků .................................................................................................................... 56 Seznam zkratek ..................................................................................................................... 58 Seznam příloh ....................................................................................................................... 59
1 Úvod Jiţ od základní školy jsem se zabýval tvorbou webových stránek. Tehdy se samozřejmě jednalo o obyčejné statické stránky, ale fascinovaly mě moţnosti, jaké nabízelo HTML, a jeho praktické vyuţití. Postupem času jsem zkoušel tvorbu desktopových aplikací, ale pro mě neměly takový potenciál, jako snadno přístupné webové stránky. Díky znalostem z desktopových aplikací jsem začal tvořit webové aplikace a zajímat se o webové sluţby. Tudíţ jsem při volbě této bakalářské práce zohlednil její vyuţití pro školu a hlavně technologii, ve které měla být aplikace vytvořena, abych mohl zúročit své nabyté znalosti. Základní kameny aplikace jsou postaveny na třívrstvé architektuře a návrhovém vzoru Singleton, který umoţňuje vytvoření jedné instance pro práci s bází dat v aplikaci. Aplikace je vytvořena pomocí technologie ASP.NET a programovacího jazyka C#. Vzhledem k mému předešlému zájmu o .NET a absolvované praxi, kde jsem se seznámil se spoustou dalších produktů od firmy Microsoft, to pro mne byla jasná volba. V dnešní době kdy jsou na aplikace kladeny vysoké nároky, především na rychlost, bezpečnost a další moţnosti jejich rozšíření a to vše při co moţná nejniţších nákladech na jejich vývoj. Je zapotřebí vyuţití mocných vývojových nástrojů jakýmţ je například Visual Studio od společnosti Microsoft. Při tvorbě bakalářské práce bylo pouţito vývojové prostředí Visual Studio 2010 Professional (jedná se o verzi dostupnou studentům zdarma). Pro úloţiště dat poslouţí Microsoft SQL Server 2008 Express (volně ke staţení) s rozšířením Management Studio určeným pro snadnější práci s bází dat. Dalším důleţitým faktorem u webových aplikací je jejich přehledný portál pro snadné ovládání, k jehoţ grafickému vytvoření jsem pouţil Adobe Photoshop CS3 Extended (zakoupena studentská licence). V průběhu tvorby webové aplikace a díky navyšujícímu se počtu souborů, důsledkem toho také nárůstu velkého mnoţství napsaného kódu jsem se rozhodl zavést verzovací systém, čili subversion. Bohuţel se mi nepodařilo sehnat studentskou verzi aplikace Microsoft Team Foundation Server a byl jsem nucen sáhnout po open-source aplikacích TortoiseSVN a AnkhSVN. Vzhledem k tomu ţe jsem nepracoval v teamu, byl tento verzovací systém dostačující. Moţná se ptáte jaký má tento verzovací systém význam pro 10
projekt, na kterém pracuje jen jedna osoba. Důvod je prostý, snadno se můţe stát, ţe se člověk přehlédne a smaţe něco, co neměl, nebo někde nějakou část aplikace upravíte a později zjistíte, ţe jiţ nefunguje tak jak má. Poté pomocí subversion snadno dohledáte změny a provedete nápravu. [1]
11
2 Vývojová prostředí 2.1 MS Visual Studio 2010 Professional Jedná se o mocný nástroj pro tvorbu aplikací. Verze Professional umoţňuje vytvářet webové či desktopové aplikace. Toto vývojové prostředí toho nabízí samozřejmě mnohem více, ale rozsah moţností i s jejich popisy by byl na několik stránek. Tento nástroj jsem si zvolil pro tvorbu bakalářské práce kvůli klíčovým vlastnostem, jako jsou snadná a rychlá tvorba webových aplikací pomocí ASP.NET, programovacího jazyka C#, jednoduché připojení databázového serveru a jeho správa pomocí integrovaných nástrojů. Mezi další klíčovou vlastnost můţeme zařadit moţnost ladění aplikace a její testování. Nejvyšší verzí tohoto nástroje je verze Ultimate, která umoţňuje zachytit vývoj aplikace jiţ od UML diagramů. Má širší moţnosti testování a pokročilejší nástroje pro práci s databází. [2]
2.2 Microsoft SQL Server 2008 Express Je výkonná platforma, která v sobě zahrnuje databázi (obsahuje data a nástroje pro manipulaci s daty) i databázový server (softwarové řešení, které například umoţňuje klientům přístup k databázi). Při vyuţití této platformy ve spojení nástroje Microsoft SQL Server Management Studio můţeme velice snadno pomocí grafického rozhraní spravovat databáze, nastavovat přístupová práva, exportovat data, měřit vytíţení databáze apod. Při tvorbě bakalářské práce byla vyuţita edice Express. Tato edice je zdarma, ale obsahuje v sobě některá omezení. Mezi nejdůleţitější omezení patří maximální velikost databáze 4G, maximální velikost operační paměti 1G a vyuţití pouze jednoho procesoru. Oproti tomu nejvyšší edice Enterprise je omezena pouze moţnostmi operačního systému Windows. [3]
2.3 Adobe Photoshop CS3 Extended Jedná se o bitmapový editor, vyuţívaný převáţně fotografy pro úpravu fotografií. Dále je hojně vyuţívám pro tvorbu webové grafiky, pro kterou jsem jej vyuţil i já při základním návrhu layoutu webu.
12
3 Využité technologie V této části krátce popíši technologie, které byly při tvorbě bakalářské práce.
3.1 ASP.NET Technologie ASP.NET pracuje nad .NET frameworkem a umoţňuje nám efektivní tvorbu webových aplikací a sluţeb. Jeho velkou výhodou je moţnost pouţití více programovacích jazyků (C#, VB apod.). Pro spuštění aplikací vytvořených pro ASP.NET je zapotřebí IIS (je součástí Windows Server i jiných edic). [4]
3.2 C# Jedná se o objektově orientovaný programovací jazyk vycházející z jazyka C++ a Java. Vytvořila jej firma Microsoft a jeho velkou výhodou je jeho moţnost pouţití s technologií ASP.NET. [5]
3.3 CSS Kaskádové styly jsou velmi silným nástrojem pro realizaci grafického návrhu webový stránek. Jejich velkou výhodou je jejich jednoduchost, ovšem největším úskalím jsou samotné webové prohlíţeče, které s kaskádovými styly nepracují stejně, coţ ve výsledku můţe znamenat úplně jiný vzhled webu a je potřeba je pro jednotlivé prohlíţeče upravit. [6]
3.4 LINQ Jedná se o integrovaný dotazovací jazyk od verze C# 3.0. Tento dotazovací jazyk nám umoţňuje vytvářet dotazy nad objekty (LINQ to Objects), databází (LINQ to SQL) a xml (LINQ to XML) soubory. V této práci jsem jej vyuţil pro práci s objekty a bází dat. [7]
3.5 JavaScript JavaScript je objektový multiplatformní programovací jazyk. Je převáţně vyuţívám ke zpracování dat na straně klienta ve webových stránkách. Jednoduchým příkladem jeho 13
pouţití je validace formulářů, například vyţádání vyplnění políčka s heslem při přihlášení do aplikace. [8]
3.6 Ajax Control Toolkit Jedná se o open-source projekt postavený na ASP.NET AJAX frameworku. Obsahuje ovládací prvky pro lepší práci s webem. Velkou výhodou je, ţe je stále rozšiřována a nyní jiţ obsahuje přes 30 ovládacích prvků. Pro příklad zde uvedu kalendář, který tato knihovna obsahuje. Jednoduše po kliknutí na nějaký obrázek, nebo jiný prvek (záleţí podle nastavení komponenty) se zobrazí jednoduchý kalendář, pomocí kterého můţete zadat datum. [9]
14
4 Analýza a návrh implementace V dnešní době, kdy jsou aplikace velice rozsáhlé a jejich tvorba díky rozsahu hodně nákladná, patří analýza ke klíčovým fázím při tvorbě software. Samotná volba technologie, na které je aplikace postavena můţe značně ovlivnit její další vývoj, dokonce samotnou existenci aplikace v budoucnu. Proto je nutné brát v potaz vyuţití a nároky kladené na aplikaci.
4.1 Porovnání s existujícím řešením Ještě před samotnou analýzou bylo nutné získat co nejvíce informací z oboru konferencí a seminářů. Na základě této potřeby jsem provedl průzkum webových stránek zabývající se touto problematikou. Nikde jsem nenarazil na webovou aplikaci s tak širokým rozsahem a univerzálním pouţitím, s jakým jsem chtěl aplikaci navrhnout. Povětšinou se jednalo o webové aplikace vytvořené speciálně pro jedinou konferenci. Často jsem narazil i na statické webové stránky. Coţ mě zklamalo, protoţe jsem stál před problémem jak vytvořit co nejuniverzálnější aplikaci a z jiných podobných řešení jsem se chtěl co nejvíce poučit, abych jiţ v počátcích předešel co nejvíce problémům.
4.2 Analýza modulů Kvůli rozsáhlosti aplikace je nutné ji rozdělit do určitých modulů, ze kterých se aplikace skládá. Toto rozdělení nám umoţní snáze určit funkcionalitou kaţdého modulu zvlášť. Takové rozloţení aplikace je velice důleţité i pro její údrţbu a další rozšiřování. To také ocení vývojář, který se s touto aplikací nikdy nesetkal. Při rozšíření, či úpravě aplikace o ní nemusí uvaţovat jako o celku, ale můţe se zaměřit pouze na funkcionalitu jednoho modulu, nebo vzájemnou funkcionalitu při komunikaci několika modulů mezi sebou. Vytvořený datový model (schéma báze dat) vychází z modulů, které jsou zde popsány. Diagram datového modulu je umístěn v příloze této bakalářské práce. Kvůli jeho rozsáhlosti jej zde nelze prezentovat v čitelné formě. Vzhledem k tomu, ţe je aplikace vytvořena pomocí objektového paradigma, rozhodl jsem se ji zde popsat v nejdůleţitějších modulech. 15
4.2.1 Portál Modul portálu je rozhraní, díky kterému můţe uţivatel zadávat pokyny webové aplikaci a webová aplikace podle poţadavku provede daný úkon (například uţivateli umoţní se přihlásit do aplikace pod určitou rolí, nebo můţe jen vypsat na úvodní stránce aktuality zadané v aplikaci apod.). Protoţe s portálem pracují běţní uţivatelé, je nutné jej navrhnout tak, aby se v něm dokázal kaţdý zorientovat co nejrychleji. Ačkoliv se můţe zdát, ţe jde o lehkou záleţitost, není tomu tak. Pro mě samotného byl obrovský problém zvolit kombinaci barev, které k sobě „ladí“ a nebudou uţivateli ztěţovat práci s portálem. Pro ukázku vkládám úvodní stránku portálu. Jak jsem psal výše, k jeho návrhu jsem pouţil aplikaci Adobe Photoshop CS3. Po nakreslení návrhu byl rozdělen do menších obrázků, které jsem následně vloţil pomocí kaskádových stylů do portálu webové aplikace.
Obrázek 1: Úvodní stránka portálu
16
4.2.2 Uživatelé Uţivatelé jsou jednou z nejdůleţitějších částí této bakalářské práce. Proto jsem se snaţil evidovat u uţivatelů co moţná nejvíce informací. Zaznamenávám zde i jejich adresu, protoţe v některých případech můţe být vyţadováno zaslání sborníku konference poštou. Registrovaní uţivatelé mají samozřejmě moţnost své osobní údaje měnit, pomocí nastavení účtu. Uţivatel s rolí administrátora můţe jiným uţivatelům zakázat přístup do aplikace. To je hlavně z toho důvodu, kdyby se podařilo nějakému “robotu“ vytvořit profil a častým procházením webu jej příliš vytěţoval. Uţivatelé dále mají moţnost při zapomenutí svého hesla, zadat heslo nové. Toto obnovení hesla se provádí pomocí odeslání e-mailu na e-mailový účet uţivatele. E-mail obsahuje speciální odkaz, pomocí kterého se provádí další kontrola před moţností zadat nové heslo.
4.2.3 Role Modul slouţí pro rozdělení uţivatelů do více skupin. Takové rozdělení je nutné, protoţe kaţdému uţivateli je určena jiná funkcionalita. Díky tomu ţe aplikace zjistí, jakou má uţivatel roli, můţe mu například přizpůsobit menu v portálu. Nepřihlášenému uţivateli se tedy nezobrazí poloţky určené pro administrátora. Jednotlivé role:
Super administrátor Tato role slouţí pouze pro vývoj aplikace. Má přístup k administraci menu, stránek, článků a uţivatelů.
Administrátor Uţivatel s rolí administrátora má také přístup k administraci článků a uţivatelů jako super administrátor, ale jeho hlavním úkolem je administrace zpravodajů, článků, konferencí a seminářů. K tomu patří administrace členů výborů, správa souborů, fotogalerií a mnoho dalšího. Dále se stará o evidenci míst konání konference, které
17
se skládají z budov a místností. Mezi jeho kompetence také patří moţnost blokování přístupu uţivatelů do aplikace.
Garant konference Tuto roli uţivatel získá aţ při přiřazení uţivatele ke konferenci s pozicí garanta. Přiřazení provádí administrátor. Hlavní funkcí garanta je kontrola “stavu“ konference. Tudíţ má přístup k přehledům plateb, příspěvků, či návštěvnosti.
Předseda konference Úkolem předsedy je sestavení programu konference. Sestavení provede vytvářením událostí zařazených do kategorií, kterým přiřadí začátek a konec konání. Dále je nutné určit, místo kde bude daná událost probíhat. To kde se událost koná, určujeme z toho důvodu, aby nenastávaly kolize s obsazeností místností. Z nedostatku času jsem jiţ bohuţel nevytvořil celkový přehled obsazení místností, coţ můţe být podmětem pro další rozšíření aplikace. Protoţe je konference rozdělena do více sekcí, má předseda moţnost určit členům výboru, které sekce mají na starosti. To se hodí převáţně pro konference s vysokou účastí a spoustou příspěvků, proto lze přiřadit i jednomu členu výboru více, či všechny sekce. Součástí této role je správa týkající se platebních údajů. Aplikace nabízí dva typy plateb (hotově a bankovním převodem). K těmto platbám můţe vytvořit pomocné články s upřesňujícími informacemi ke zvolené konferenci. Vzhledem k tomu ţe spravuje tyto informace, je v jeho kompetenci určení cen událostí a zároveň také samotné konference.
18
Obrázek 2: Ukázka ze stránky s nastavením cen konference a událostí v konferenci
Člen programového výboru Úkolem člena programového výboru je pečovat o přidělenou sekci. Aplikace samozřejmě nabízí přidělit více sekcí jednomu členu výboru. Ti také mohou schvalovat příspěvky, zamítnout je, nebo je vrátit k přepracování. Dále mají moţnost poznamenat si ke kaţdému příspěvku interní poznámky.
4.2.4 Menu Při analýze tohoto modulu jsem dlouho zvaţoval, jakým způsobem bude menu řešeno. Hlavně jsem se chtěl vyvarovat řešením, kde se menu musí vytvářet samostatně pro kaţdou roli zvlášť. Takové řešení by obnášelo pro poloţky v menu, které mají role společné, vytvářet stejné poloţky a v případě jejich změny tyto poloţky měnit pro všechny role. Sice je toto řešení asi nejméně náročně na výkon serveru, kde webová aplikace poběţí, ale s dalším ohledem na lokalizaci aplikace by případné změny v menu vedli k ještě sloţitějším úpravám. To samé platí i pro rozšíření lokalizace o další jazyky. Proto jsem se rozhodl
19
vytvořit systém, ve kterém se poloţkám menu přidělují oprávnění jednotlivých rolí, kde kaţdá poloţka menu můţe mít přidělena více rolí. Díky tomu jsou informace o poloţkách menu snadno upravitelné, protoţe jsou udrţována na jednom místě. U poloţek menu se dále evidují dodatečné informace, mezi něţ patří informace o tom, zda je poloţka v menu potomkem jiné poloţky, či je jen následníkem poloţky. V praxi to znamená, ţe se menu sestavuje jako strom poloţek, čímţ můţeme vytvářet víceúrovňová menu. S ohledem na grafický návrh jsem vytvořil pouze menu umoţňující jen jednu podúroveň, coţ je pro mojí aplikaci dostačující (omezení úrovní je dáno způsobem zobrazení menu v portálu, ale logická vrstva můţe vytvářet více úrovní). Na obrázku níţe je ţlutou barvou zvýrazněna podúroveň pro poloţku “konference“ po najetí kurzoru myši.
Obrázek 3: Ukázka druhé úrovně poloţek v menu
Při samotném sestavení menu se podle role uţivatele vyberou pouze poloţky menu, které mají tuto roli přidělenou, čímţ automaticky zamezíme zobrazení poloţek, které se nesmí zobrazit uţivateli s jinou rolí. Vybrané poloţky se dále sestaví do úrovní a zobrazí. Na následujícím obrázku je uvedena ukázka zobrazení menu v aplikaci.
20
Obrázek 4: Ukázka stromové struktury poloţek v menu aplikace
Toto řešení je velice náročné na výkon serveru, proto byl v databázi vytvořen takzvaný pohled (View – vytvořený SQL dotaz) s názvem “vw_PageIDListForMenu“. Slouţí pro zjištění rolí všech poloţek, aby nebylo prováděno zjištění rolí pro kaţdou poloţku samostatně. U pár poloţek menu s malým počtem rolí by to nebylo nutné, ale u rozsáhlejších aplikací by takové časté čtení z databáze znamenalo enormní výkonové nároky. Po úplném sestavení menu dojde k jeho uloţení do Session, ze které se provádí čtení při kaţdém načtení stránky. Při změně role (ke změně role dojde po přihlášení, nebo odhlášení z webové aplikace) se znovu provede načtení a sestavení celého menu.
4.2.5 Stránky Modul stránek pracuje s modulem Menu, kde se po výběru poloţky menu provede načtení stránky, kterou poloţka představuje. Z toho důvodu se role přidělené poloţce v menu aplikují i na stránku, která k poloţce patří. Toto je velice výhodná vlastnost, protoţe při načtení stránky lze zjistit, zda má uţivatel přidělenou roli jako stránka, kterou chce uţivatel
21
zobrazit. Pokud uţivatel “nevlastní“ potřebnou roli, je přesměrován na výchozí stránku (default.aspx – úvodní stránka slouţící pro zobrazení aktualit). Zde jsem také zohlednil náročnost aplikace na výkon serveru a rozdělil jsem stránky na dvě skupiny. Předešlé řádky popisují první skupinu stránek vyţadující kontrolu přístupu uţivatelů podle rolí. Protoţe aplikace můţe obsahovat spoustu stránek, u kterých není potřeba kontrolovat role pro přístup uţivatele, byla vytvořena druhá a třetí skupina. Dělení stránek:
Stránky vyţadující kontrolu při přístupu podle rolí. Tato skupina stránek je označena názvem “LoginPage“, z čehoţ vyplívá, ţe poţadují i přihlášení uţivatele. Převáţně se jedná o stránky určené k administraci, či stránky, ve kterých je nutná plná kontrola uţivatele, pracujícího s daty (tím můţe být například stránka pro vkládání příspěvků do konference).
Stránky nevyţadující kontrolu při přístupu uţivatele podle rolí. Do této skupiny jsou zařazeny stránky obsahující převáţně informace určené všem uţivatelům (pro příklad zobrazení informací o konferenci). Skupinu jsem označil “NoLoginPage“. Jak název napovídá, není zde pro přístup vyţádáno ani přihlášení uţivatele.
Stránky bez speciální funkcionality. Jedná se o speciální skupinu stránek, které nejsou vytvořeny jako soubory ve formátu “název.aspx“, ale existují pouze jako články v databázi. Více se o typu těchto stránek dozvíte v popisu modulu “Články“. Na následujícím obrázku nejsou znázorněny,
protoţe
jsou
prakticky
řešeny
jako
podskupina
skupiny
“NoLoginPage“.
22
Obrázek 5: Základní dělení webových stránek
4.2.6 Články Jedná se o modul, který byl zaveden aţ v průběhu vývoje. Vzhledem k tomu, ţe jsem se snaţil vytvořit co nejvíce obecnou aplikaci pro řízení konferencí a seminářů, bylo vhodné zavést systém vytváření webových stránek bez nutnosti vytvoření souboru obsahující webovou stránku pouze s textem. Čili stránky bez speciální funkcionality. Také bylo nutné zachovat vlastnosti normálních stránek, které mohou být vloţeny v menu, automaticky se generující zanoření stránky v aplikaci, nebo zobrazení nadpisu stránky. Pro zachování všech potřebných vlastností pro kompatibilitu ovládacích prvků v aplikaci se tyto stránky ve formě článků vytvářejí jako obyčejné stránky, ale při jejich vytvoření jim je přiřazen článek, který mají zobrazit. Tím docílíme udrţení všech potřebných informací, co mají běţné stránky. Díky informaci přiřazení nějakého článku dané stránce aplikace automaticky při generování menu upravuje odkazy poloţek na speciální stránku. Tato speciální stránka se jmenuje “ArticlePage.aspx“. Do odkazu poloţky v menu se ještě přidává parametr “article“, jehoţ hodnota je identifikátor daného článku, aby stránka “ArticlePage.aspx“ věděla, jaký článek má zobrazit.
23
Hlavní vlastnosti modulu:
Mohu vytvořit webovou stránku, aniţ bych musel “fyzicky“ stránku vytvářet.
Prakticky ţádný rozdíl od běţných stránek.
Celé vytvoření článku (stránky) je moţné provést z administrace aplikace.
Snadná úprava obsahu stránky.
Obrázek 6: Administrace článků
Pro ukázku dalších moţností těchto článků můţe být nějaké “pomocné“ menu, které na články odkazuje. V mé bakalářské práci je umístěno vpravo dole.
Obrázek 7: Pomocné menu vyuţívající články
24
4.2.7 Úvodní články Slouţí pro výpis novinek a různých informací týkajících se konferencí apod. Můţeme určit časové vymezení, kdy se má článek zobrazovat. To je výhodné pro usnadnění práce, abychom nemuseli sledovat, zda se nezobrazují příliš staré články, nebo články týkajících se například zahájení konference, která jiţ proběhla. Aby bylo zabráněno zobrazení článku, který není dokončený a má špatně nastavené datum, nebo je určen pro stálé zobrazení, je nutné článek i publikovat. Také aplikace umoţňuje zrušit publikování, coţ je výhodné i pro jeho rychlé skrytí, abyste nemuseli stále měnit datum. Dále aplikace nabízí zobrazování článků s vysokou prioritou, coţ provede zařazení článku před všechny ostatní články s normální prioritou. To administrátorům umoţňuje snáze informovat uţivatele například o plánované odstávce webu.
Obrázek 8: Administrace článků pro úvodní stránku
25
4.2.8 Konference Jedná se o jeden z nejdůleţitějších modulů. Ale kvůli jeho rozsáhlosti vyuţívá několik dalších modulů, které jsou v této práci popsány. Snaţil jsem se v něm evidovat co moţná nejvíce informací a ty nejdůleţitější zde uvedu. Hlavní atributy modulu:
Název konference.
Popis konference.
Zaměření konference.
Časové údaje týkající se konference (začátek, konec, termíny registrací apod.).
Ceny registrací.
Účetní údaje.
Dokumenty konference (program, sborník).
Dodatečné informace.
Dále samozřejmě přebírá atributy z jiných modulů, se kterými pracuje (místo konání, výbory,…).
4.2.9 Události Protoţe jsem se snaţil vytvořit co moţná nejvíce univerzální aplikaci, bylo nutné vytvořit modul, pomocí kterého budeme moci evidovat události konané v průběhu konference. Bez tohoto modulu by bylo při rozšíření aplikace upravovat velkou část aplikace. Ale při pouţití tohoto modulu jen vytvoříte nové události a ty přiřadíte konferenci a ty se automaticky při zobrazení informací o konferenci, nebo například při registraci automaticky generují. Velkou jejich výhodou je přiřazení události její cenu. Cena můţe být samozřejmě nulová a událost je pak evidována, jako ţe je zdarma. Dále můţe být cena označena jakou součást registračního poplatku a uţivateli se událost nezobrazuje při výpočtu celkové ceny konference. Pro ukázku zde uvedu jednoduchý příklad. Při registraci na konferenci si 26
uţivatel volí, ve které dny chce mít oběd. Kdyţ bude cena větší neţ 0, bude mu připočtena k výsledné ceně. Pokud bude cena 0, zobrazí se uţivateli oběd jako zdarma a nebude muset za něj platit a na víc bude mít pocit, ţe dostal něco zadarmo. Oproti tomu volba ceny události jako součást registračního poplatku se hodí u doprovodných akcí.
4.2.10 Příspěvky Modul “Příspěvky“ je určen pouze pro konference. Je určen uţivatelům, kteří se registrují na konferenci s příspěvkem. Dále je určen pro členy programového výboru, kteří provádějí schvalování příspěvků. Pro lepší představu nejdříve uvedu obrázek, na kterém je editace příspěvku.
Obrázek 9: Editace příspěvku
Jak je z obrázku zřejmé, uţivatel zadává název příspěvku, dále můţe nahrát soubory s abstraktem, příspěvkem a případně i plakát. Dále se volí umístění příspěvku do sekce konference, jazyk v jakém bude příspěvek prezentován. Také je nutné zvolit, zda chce uţivatel příspěvek jen prezentovat, nebo zda bude i umístěn do sborníku, případně vyvěšen jako plakát. Nutnost vloţení souboru s plakátem se zobrazí aţ po zvolení moţnosti
27
“Vyvěsit jako plakát“. Pokud by měl příspěvek více autorů, můţe je uţivatel jednoduše připsat a ještě vloţit poznámku k příspěvku. Nahrané soubory můţe uţivatel opětovně stahovat, nebo jej můţe nahradit novým souborem. Další samozřejmostí je moţnost vloţit více příspěvků. Počet není nijak omezen. Při schvalování příspěvku se členům výboru zobrazí při editaci příspěvku další formulář. Pomocí tohoto formuláře můţe příspěvek buďto schválit, zamítnout, nebo vrátit k přepracování. Důleţité zde je, ţe se neschvaluje příspěvek jako celek, ale jako samostatné části z pole nazvaném “Příspěvek chcete“. Je to z toho důvodu, aby článek původně určený pro prezentaci mohl být určen jen pro vyvěšení apod. Jinak by bylo nutné zamítnout celý příspěvek a vše vyplňovat znovu. Coţ by bylo zbytečné. Člen programového výboru si můţe psát i interní poznámky ve schvalovacím formuláři.
Obrázek 10: Formulář pro schvalování příspěvků
4.2.11 Místa konání, budovy, místnosti Jedná se o tři moduly, které jsou mezi sebou velice silně svázány. Jak jiţ jejich názvy napovídají, slouţí k evidenci celého místa konání konferencí a seminářů. V podstatě je celé místo konání seskupením budov a seminářů. V administraci webové aplikace lze místu konání, budově, nebo místnosti vyplnit článek, který slouţí k popisu daného místa. Místnosti v sobě udrţují i informaci o její kapacitě. Coţ nám můţe při plánování konference/semináře usnadnit práci při správné volbě místností. Vzhledem k evidenci 28
těchto informací by bylo vhodné při dalším rozšiřování aplikace je vyuţít a například kontrolovat kolize obsazenosti místností (v celé aplikaci je dostatek informací, aby se dalo zjistit, zda ke kolizím dochází), nebo pro uţivatele více zpřehlednit samotné místo konání pomocí ukládaných článku v těchto modulech.
Obrázek 11: Ukázka administrace místa konání Venue
Building
id
id
name
name
text
text venue
Room id name capacity text building
Obrázek 12: Ukázka návrhu modulů pro místa konání v datové vrstvě
4.2.12 Semináře Modul je velice podobný modulu “Konference“, proto zde uvedu hlavní rozdíly. Jedním z nejdůleţitějších rozdílů je absence výborů u semináře. O administraci semináře se stará pouze administrátor. Ale administrátor určuje uţivatele, kteří seminář povedou (lektory). Dále se u semináře volí jeden ze dvou jazyků, v jakém bude veden (angličtina a čeština). Také je zde moţnost omezit maximální počet účastníků, podle místa konání semináře. Pro ukázku zde uvedu formulář z administrace semináře (podobný formuláři k administraci konference).
29
Obrázek 13: Ukázka formuláře v administraci semináře
4.2.13 Doprovodné akce Zde bylo nutné zváţit, jakým způsobem lze modul pro doprovodné akce v konferenci prezentovat. Nelze je jednoduše řešit pouhým článkem s textem. Je vhodné evidovat další informace, jako termín konání nebo i cenu doprovodné akce. Nejlépe se hodilo doprovodné akce zařadit jako nový typ události. Čili spadá pod modul “Události“ a umoţňuje evidovat dodatečné informace. Současně lze díky zařazení do událostí provádět jednoduše výpočet celkové ceny konference.
4.2.14 Výbory Modul je určen pouze pro konference. Slouţí pro přidělení rolí uţivatelům, kteří mají konferenci na starosti. 30
Výbory jsou rozděleny na programový a organizační výbor. Vzhledem k tomu, ţe členové organizačního výboru nemají ve webové aplikaci ţádnou rozšířenou funkcionalitu, nebudu se jimi zde zabývat. Oproti tomu členové programového výboru jsou rozděleni do několika rolí. Tyto role jim jsou administrátorem přiděleny pro kaţdou konferenci zvlášť. Takţe se členům výboru rozšíří funkcionalita jen pro určitou konferenci a ne automaticky pro všechny. Organizační výbor je rozdělen na garanta, předsedu a normálního člena organizačního výboru. Kaţdá konference můţe mít pouze jednoho garanta a předsedu. Jejich hlavním úkolem je sledování stavu konané konference a normální členové se starají přímo o samotné příspěvky.
4.2.15 Ubytování, propagace města a školy Mělo se jednat o dva samostatné moduly. Vzhledem k tomu ţe by jejich obsah byl jen text a obrázky bez funkcionality, byly vytvořeny za pomocí modulu “Články“. Vlastně mě moduly pro ubytování a propagaci přiměly k vytvoření modulu pro články.
4.2.16 Platby/Účast Zde popíši současně modul “Platby“ a modul “Účast“. Je to z toho důvodu, protoţe v bakalářské práci byly sloučeny do jednoho kontrolu (speciální ovládací prvek, který jsem vytvořil – jeho velkou výhodou je snadné opětovné pouţití na více stránkách). Kontrol obsahuje i filtr pro snazší vyhledávání osob podle určitých parametrů. Pokud má uţivatel roli administrátora, můţe jednotlivým uţivatelům přihlášených na konferenci nastavit, zda jiţ zaplatili registrační poplatek, nebo zda se konference zúčastnili. Další moţností je upravit výslednou cenu registrace. Tuto moţnost jsem přidal z toho důvodu, aby cena nebyla pro kaţdého “pevná“ a pokud by se jednalo například o speciálního hosta, aby nemusel platit registrační poplatek. Tyto získané hodnoty mohou dále slouţit pro vytvoření různých statistik. Statistiky jsem původně chtěl navíc vytvořit, ale z nedostatku času to nebylo moţné. V tomto modulu je také velký prostor pro jeho další rozšíření. Pro snazší evidenci plateb by bylo vhodné vytvořit sluţbu (př.: Windows Services), která by se připojila k bankovnímu účtu a podle účetních údajů by zjistila přišlé platby pro konferenci/seminář a označila zaplacené poloţky. Jako další rozšíření bych navrhoval
31
vytvoření nového kontrolu, který by po přihlášení uţivatele do webové aplikace zobrazil v nějakém informační panelu stav jeho plateb, případně by mohla vytvořená sluţba rozesílat e-maily uţivatelům o doručení platby. Při registraci na seminář, či konferenci, si uţivatel volí, zda provede platbu hotově nebo bankovním převodem. Nebylo by ovšem špatné přidat i platby pomocí platebních karet. Nejedná se o jednoduchou záleţitost (banky platbu kartou neřeší jednotným způsobem), proto jsem se o to zde ani nepokoušel, ale jisté zkušenosti uţ s touto problematikou mám. Na obrázku níţe je ukázka kontrolu umístěného ve stránce pro evidenci plateb a účasti. Jména účastníků jsem na následujícím obrázku záměrně rozostřil.
Obrázek 14: Ukázka kontrolu pro modul Platby/Účast pro administrátora
4.2.17 Zpravodaje Rozesílání zpravodajů nebylo v zadání bakalářské práce, ale přišlo mi vhodné je do ní zařadit. Zpravodaje můţe vytvářet pouze administrátor. Aby se co nejvíce omezila chybovost textu ve zpravodajích, musí kaţdý zpravodaj projít schvalováním. Tudíţ má 32
zpravodaj několik stavů. Prvním stavem je koncept. Tento stav se u zpravodaje nastaví přímo po vytvoření zpravodaje. Při další editaci jej lze uloţit zpět do konceptů, nebo schválit, coţ provede rozeslání zpravodaje všem administrátorům, aby jej mohli překontrolovat. A jako poslední krok se provede načtení příjemců zpravodaje a odeslání. To jestli chce uţivatel zpravodaj přijímat, určí v nastavení svého profilu.
Obrázek 15: Ukázka stránky pro práci se zpravodaji
4.2.18 Lokalizace Jedním z hlavních poţadavků bylo vytvořit lokalizaci aplikace do dvou jazyků (čeština a angličtina). Vzhledem k tomu, ţe jsem se snaţil vytvořit co moţná nejvíce pruţný systém, kde půjdou vkládat a upravovat texty dynamicky bez zásahu do zdrojového kódu aplikace musel jsem vyřešit jak texty uchovávat. Prvním řešením bylo pouţít dvě báze dat. Zde by se po volbě jazyka přenastavilo připojení k bázi dat na jinou, coţ by znamenalo vkládání všech dat nadvakrát. Proto jsem se rozhodl pro jiné řešení, kde jsou všechny dynamicky 33
vkládané texty uchovávány v tabulce Dictionary (slovník) v jedné bázi dat. Kvůli tomuto řešení bylo také nutné vytvořit v logické vrstvě pomocné třídy pro komunikaci slovníku s třídami pracujícími s texty. Velkým negativem tohoto řešení je náročnost na výkon při častém dotazování se do databáze při výběru textů ze slovníku. Tuto negativní vlastnost lze řešit několika způsoby, a proto jsem od tohoto řešení neopustil. Velkým pozitivem je snadná rozšiřitelnost lokalizace o více jazyků bez velkého zásahu do aplikačního kódu.
Obrázek 16: Struktura tabulky slovníku v bázi dat
Obrázek 17: Třídy pro práci se slovníkem
34
Obrázek 18: Ukázka stránky pro vytvoření překladů s WYSIWYG editorem
Pro texty, které jsou určené přímo pro portál (texty validátorů, chybových hlášení, tlačítek apod.) jsem vyuţil takzvaných “Global Resources“ a “Local Resources“. Díky těmto zdrojům můţete snadno vytvořit v aplikaci lokalizaci. “Global Resources“ je určen pro celou aplikaci a “Local Resources“ pro jednotlivé stránky. Obsahují soubory v XML formátu a přípony souborů určují, pro jaký jazyk jsou určené. Na obrázku níţe je zachycené umístění těchto zdrojů v projektu.
35
Obrázek 19: Ukázka resources v projektu
Protoţe je jeden jazyk zvolen jako defaultní, není u zdrojů v adresáři “cs“ uvedeno jazykové nastavení pro češtinu. Při volbě angličtiny pomocí ikonky v portálu, dojde k přenastavení jazykového nastavení aplikace na “en-US“ a ta při poţadavku o text sáhne do defaultního souboru s texty (patřičný text nalezne podle jedinečného klíče). Pokud daný klíč nalezne, zkusí najít stejný soubor zdrojů obsahující příponu “en-US“ a v něm zkusí nalézt stejný klíč. Pokud jej nalezne, vezme anglický text, pokud klíč nenalezne, vezme text z defaultního zdroje. Zde je důleţitá posloupnost hledání klíče. Pokud nebude existovat defaultní soubor se zdroji a v něm patřičný klíč, nebude nalezen ani patřičný klíč v souboru určeném pro angličtinu. Tuto posloupnost hledání zdrojů jsem neznal a dlouho jsem řešil, proč mi překlady nefungují, proto to zde uvádím. Nyní nastíním ukázku propojení textu z ovládacího prvku s “Local Resources“. Uvádím zde nejčastější způsob čtení ze zdrojů v mé bakalářské práci. Ovládací prvek je umístěn v souboru “login.aspx“, tudíţ se defaultní zdrojový souboru s texty musí jmenovat “Login.aspx.resx“. [12] Ovládací prvek ve stránce:
Klíč ve zdrojovém souboru: “locHelpResource1.Text“
36
Jak vidíte, celkový klíč je tvořen z názvu klíče umístěném v ovládacím prvku a přes tečku spojený s atributem ke kterému patří.
Obrázek 20: Ukázka obsahu zdrojového souboru (resources) pro lokalizaci aplikace
Jak jsem uvedl výše, defaultním jazykem je čeština. Při volbě jiného jazyka se vytvoří cookie pomocí kterého se při nové návštěvě webové aplikace automaticky nastaví zvolený jazyk.
37
5 Popis třívrstvé architektury aplikace Pro tvorbu webových aplikací se často vyuţívá rozdělení aplikace do tří vrstev. Takovéto rozdělení jsem pouţil i v bakalářské práci, protoţe je pro rozsah aplikace dostatečné a mám s ním jiţ zkušenosti. Rozdělení do vrstev slouţí k oddělení jednotlivých částí aplikace. Kaţdá část má za úkol provádět jinou činnost a v podstatě zapouzdřuje určitou funkcionalitu (práci s daty apod.). To nám přináší snadnější správu aplikace z hlediska rozšiřování, nebo i jednoduchých úprav. Z počátku se můţe při tvorbě jednotlivých vrstev uţivateli zdát toto rozdělení zbytečné, ale při větší rozsáhlosti a sloţitosti aplikace takové rozdělení nakonec ocení. [11] Pro snazší představu uvedu nejdříve jednoduchý diagram třívrstvé architektury aplikace a poté popíši jednotlivé vrstvy.
Obrázek 21: Základní diagram třívrstvé architektury webové aplikace
Jak je z diagramu výše zřejmé, prezenční vrstva slouţí ke komunikaci s aplikační vrstvou a aplikační vrstva komunikuje s datovou vrstvou. Na první pohled vypadá toto rozloţení jednoduše a jasně. Velice důleţité je neporušit návaznost komunikací mezi vrstvami. Ovšem při prvních pokusech tvorby těchto vrstev můţe mít programátor problém s rozvrţením aplikace do jednotlivých vrstev. Kdyţ jsem se s touto problematikou začal zabývat, měl jsem nutkání aplikační vrstvu úplně vynechat, coţ se na konec ukázalo jako veliká chyba. Dokonce existují vývojové nástroje, které kontrolují, zda nebyla návaznost vrstev porušena. Jedním z takových nástrojů je Visual Studio 2010 Ultimate. Pro praktické znázornění ještě přidávám snímek rozloţení vrstev v “Solution“ ve Visual Studiu.
38
Obrázek 22: Rozloţení třívrstvé architektury ve Visual Studiu
Celé “Solution“ se skládá ze tří projektů, coţ jsou jednotlivé vrstvy. Projekt s názvem “vspjConference“ je prezenční vrstva. Projekt “BL“ (logická vrstva) a “DL“ (datová vrstva) jsou po publikování aplikace (sestavení webové aplikace pro její spuštění v IIS) sestaveny do knihoven (soubory s příponou “.dll“) a projekt “vspjConference“ je rozdělen do knihovny
a webových stránek. Adresář DLL obsahuje pomocné knihovny, jakou je
například “AjaxControlToolkit.dll“.
5.1 Prezenční vrstva (presentation layer) Prezenční vrstvu si můţete jednoduše představit jako webové stránky (v ASP.NET soubory s příponou .aspx). Na těchto stránkách se zobrazí nějaký text, či formulář kde vyplníme nějaké informace). Jejím hlavním úkolem je tedy zobrazit uţivateli potřebná data. Data, která se mají zobrazit, získá z aplikační vrstvy, pomocí metod které jí nabízí. Dá se zde vyuţít interface, kterým bude přesně definováno, jaká data jsou prezenční vrstvě přístupná. Komunikační rozhraní jsem řešil pouze pomocí nastavení oprávnění tříd v aplikační vrstvě (public, protected, private).
5.2 Aplikační vrstva (business logic layer) Hlavník úkolem aplikační vrstvy je komunikace s datovou vrstvou (načítaní, ukládání, či aktualizace dat), zpracování načtených dat a předání zpracovaných dat prezenční vrstvě. Pro nejsnazší pochopení účelu této vrstvy uvedu jednoduchý příklad. Uţivatel zadá v prezenční vrstvě svůj login (v mé bakalářské práci je login reprezentován e-mailem uţivatele) a heslo. Nyní je potřeba vytvořit kontrolní otisk hesla pomocí hashovacích algoritmů (vyuţívám MDA5 a SHA-1). Vytvoření otisku je právě úkolem aplikační vrstvy. 39
Nakonec aplikační vrstva porovná kontrolní součet hesla zadaného uţivatelem s kontrolním součtem získaným z datové vrstvy. A podle výsledku oznámí prezenční vrstvě, zda k přihlášení došlo. Při samotném přihlášení se provádí samozřejmě více úkonů, neţ zde popisuji, ale o vše se postará aplikační vrstva a prezenční vrstva na výsledek nějak zareaguje, aniţ by věděla, jakým způsobem se data zpracovávala. Coţ je také hlavním smyslem rozdělení aplikace do několika vrstev
5.3 Datová vrstva (data access layer) Datová vrstva slouţí pro komunikaci s bází dat (databází). Jejím hlavním úkolem je tedy provádět samotné načítání, ukládání případně aktualizace dat. Abych nemusel tuto datovou vrstvu celou programovat, pouţil jsem technologii “LINQ“. Podrobněji se touto technologií zabývám v kapitole “Pouţité technologie“. Zde jen popíši praktické pouţití v datové vrstvě. Do projektu “DL“ se přidá poloţka nazvaná “LINQ to SQL Classes“, čímţ se vytvoří soubor s příponou “.dbml“ (dostupné od verze .NET 3.5). Po jeho vytvoření se v projektu vytvoří takzvaný “DataContext“. Do tohoto souboru se umístí struktura databáze i s připojením do databáze. Po vytvoření instance z DataContextu můţeme přistupovat k datům v databázi. Ukázka načtení všech uţivatelů z databáze: // Vytvoření instance z DataContextu DL.vspjConferenceDataContext db = new DL.vspjConferenceDataContext(); // načtení všech uživatelů List users = (from u in db.Users select u).ToList();
Načtení lze provádět více způsoby a umoţňuje podobné dotazy jako SQL. Při vykonání výsledného dotazu totiţ dojde k “přepisu“ dotazu do formy SQL, kterému databáze rozumí.
40
6 Ovládací prvky Visual Studio umoţňuje vývojářům pouţívat jiţ předvytvořené ovládací prvky (kontroly, komponenty), nebo můţeme vytvořit své vlastní, které se skládají ze skupin jiných komponent nebo rozšiřují jiţ ty základní (pomocí dědičnosti).
6.1 CommandToolbar (lišta s příkazy) Ovládací prvek slouţí k zobrazení příkazů, které lze na dané stránce provádět. Pokud tedy stránka umoţňuje nějaké příkazy, nastavíme ovládací prvek do určitého reţimu a on nám poté zobrazí dostupné příkazy. Pro lepší pochopení tohoto ovládacího prvku přikládám ukázku ze stránky zobrazení konference, na kterou mají přístup i nepřihlášení uţivatelé. Ovládací prvek je nastaven do reţimu “SelectedConference“.
Obrázek 23: Ukázka ovládacího prvku CommandToolbar v reţimu SelectedConference
Ovládací prvek se nestará jen o pouhé zobrazení příkazů. V tomto případě i zjišťuje, zda jsou soubory ke staţení přístupné a pokud některý z nich není, není ani zobrazen.
41
6.2 Conference (přehled informací o konferenci) Úkolem tohoto ovládacího prvku je pouhé zobrazení informací o konferenci. Byl vytvořen, protoţe je potřeba informace o konferenci zobrazovat na více místech. Kdybych jej nevytvořil, tak bych byl nucen stále přepisovat stejný kód. Coţ by nebylo aţ tak hrozné, ale kdyby došlo k nějaké změně, nebo přidání nových informaci ke konferencím, byly by úpravy příliš časově náročné. Tento kontrol stačí umístit do stránky a při načtení stránky do něj vloţit instanci konference, kterou má zobrazit.
6.3 FileUpload Protoţe webová aplikace pracuje se soubory, byl vytvořen ovládací prvek určený k nahrávání souborů na server. Je vytvořen tak, aby byl co nejvíce konfigurovatelný. Ovládacímu prvku můžeme nastavit tyto vlastnosti:
Typ souboru, který chceme nahrát. o None – výchozí hodnota, pokud se pokusíme nahrát nějaký soubor, dojde k vyjímce (exception) a pádu aplikace, slouţí pouze ke kontrole inicializace ovládacího prvku o Document – pro nahrání souborů z aplikace Microsoft Office Word o PDF o Image – zatím podporuje jen soubory typu “jpeg“, ale lze je snadno rozšířit i o další formáty
Nový formát názvu souboru.
Maximální velikost souboru (lze měnit z konfiguračního souboru aplikace).
Cílové umístění nahraného souboru.
Nadpis, který má komponenta zobrazit.
42
Po dokončení nahrávání souboru můžeme z komponenty vyčíst tyto vlastnosti:
Název souboru.
Příponu souboru.
Název uloţeného souboru.
Velikost souboru.
Výsledný stav nahrávání souboru.
Po nahrání souboru je nutné měnit jeho název. Pokud by bylo nahráno více souborů se stejným názvem, došlo by k jejich přepsání. Z toho důvodu název nahraného souboru sloţen z časové stopy a identifikátoru uţivatelé, který jej nahrál. Aplikace ovšem uchovává i původní název souboru a při jeho staţení je jiţ soubor pojmenován podle původního názvu. Je zde nutné zmínit, ţe typy souborů nejsou kontrolovány podle přípony, ale skutečně se testuje, o jaký typ souboru jde.
Obrázek 24: Ukázka ovládacího prvku FileUpload pro nahrávání souborů na server
6.4 HTMLEditor Ve webové aplikaci je potřeba často psát nějaké články. Z toho důvodu jsem vyuţil i WYSIWYG editoru s názvem CKEditor. Protoţe jsem si nebyl jist, pod jakou licenci bude bakalářská práce spadat a tento editor lze volně šířit jako doplněk, vytvořil jsem proto tento ovládací prvek. Jeho hlavním úkolem je zjistit zda je v aplikaci nahrán CKEditor, pokud ano zobrazí jej. Jestliţe editor není nalezen, bude zobrazen obyčejný textbox, který nám neumoţní tak komfortní psaní jako CKEditor. Ukázku CKEditoru si můţete, prohlédnou na obrázku „Obrázek 18: Ukázka stránky pro vytvoření překladů s WYSIWYG editorem“. [10] 43
6.5 Menu Ovládací prvek je umístěn v MasterPage (je to hlavní stránka do které se vkládá obsah ostatních stránek a ASP.NET také umoţňuje skládat více MasterPage dohromady) a slouţí pro vygenerování celého menu. Není potřeba jej nějak nastavovat. Sám zjistí, jestli je uţivatel přihlášený a pokud ano, tak zjistí jakou má roli a provede sestavení menu z poloţek. Ukázku vygenerovaného menu si můţete prohlédnout na obrázku “Obrázek 3: Ukázka druhé úrovně poloţek v menu“.
6.6 PageControl Ovládací prvek je vyuţívám při vytvoření a editaci poloţky v menu (webové stránky). Můţeme v ní nastavit spousty atributů. Zde uvedu pouze ukázku, ze které bude snad vše jasné.
Obrázek 25: Ukázka ovládacího prvku PageControl pro vytvoření/editaci stránek
44
6.7 PaymentAttendenceControl (Platba/Návštěvnost) Jak jiţ název napovídá, ovládací prvek je určen k administraci plateb a návštěvnosti konference. Kontroluje oprávnění uţivatele, a pokud má patřičnou roli, zobrazí mu pomocná tlačítka pro evidenci návštěvnosti plateb, či změnu cen jednotlivých registrací apod. Pokud uţivatel nemá dostatečné oprávnění pro administraci, zobrazí se mu pouze informace o platbách a návštěvnosti, ale nemůţe provádět ţádnou jejich změnu. Pro lepší orientaci ve větším mnoţství registrací, obsahuje ovládací prvek i jednoduchý filtr pro vyhledávání v registracích. Ukázka ovládacího prvku i s filtrem je na obrázku “Obrázek 14: Ukázka kontrolu pro modul Platby/Účast pro administrátora“.
6.8 PaymentAttandenceSeminarControl Je téměř totoţný s ovládacím prvek “PaymentAttendenceControl“, ale byl vytvořen rovnou vytvořen zvlášť, protoţe jsou registrace konferencí a seminářů oddělené a při dalším rozšiřování registrací konferencí nebo seminářů by bylo nutné jej stejně vytvořit.
6.9 PostControl Ovládací prvek je určen k administraci všech příspěvků konference. Účastníci konference díky němu mohou spravovat svoje příspěvky, nahrávat soubory, stahovat je, či nahrazovat. Informace které u příspěvků lze evidovat:
Název příspěvku
Nahrát abstrakt
Nahrát příspěvek
Nahrát plakát
Volbu sekce
Jazyk příspěvku o Čeština 45
o Angličtina o Slovenština
Spoluautory
Poznámku
Umístění příspěvku o Prezentace o Sborník o Vyvěsit jako plakát
Samotné schvalování příspěvků se provádí podle umístění příspěvku. Pokud uţivatel zvolil, ţe chce příspěvek prezentovat, musí člen programového výboru schválit prezentaci. Pokud uţivatel zvolil i umístění příspěvku do sborníku, musí jej člen výboru také schválit zvlášť. Schvalování se provádí přes schvalovací formulář, který je součástí tohoto ovládacího prvku. Můţete si jej prohlédnout na obrázku “Obrázek 10: Formulář pro schvalování příspěvků“.
6.10 SeminarControl (přehled informací o semináři) Ovládací prvek je zaloţený na stejném principu jako ovládací prvek “Conference“. Liší se pouze v jeho inicializaci. Zde je vyţádán pouze identifikátor (id) semináře a o načtení semináře se postará samotný ovládací prvek.
6.11 SiteMapControl (mapa stránek) Jedná se o ovládací prvek pouţívaný pouze v administraci. Jeho ukázku můţete vidět na obrázku s názvem “Obrázek 4: Ukázka stromové struktury poloţek v menu aplikace“. Slouţí k zobrazení všech stránek i s jejich oprávněním. Po menších úpravách tohoto ovládacího
46
prvku by jej šlo vyuţít i na vytvoření takzvané mapy stránek, která by byla přístupná všem uţivatelům.
6.12 SiteMapPath Ovládací prvek je umístěný v MasterPage pod prvkem Menu. Slouţí pro zobrazení celé cesty zanoření ke stránce a umoţňuje tak rychlý návrat ke stránce s vyšší úrovní a zpřehledňuje uţivateli orientaci na webu.
Obrázek 26: Ukázka ovládacího prvku SiteMapPath znázorňujícího zanoření stránky
6.13 SponsorsToolbar Tento ovládací prvek nemá ţádnou speciální funkci. Je určen jen pro zobrazení dalších moţností rozšíření aplikace. Ač se to nezdá, téma konference je opravdu velice rozsáhlé a z časových důvodů jsem nemohl do aplikace zanést všechny tak jak bych si představoval.
6.14 Time Tento jednoduchý ovládací prvek umoţňuje v aplikaci jednoduše pracovat s časem. Čili s ním můţeme nastavovat hodiny a minuty. Nikde se mi bohuţel nepodařilo najít nějakou komponentu, která by práci s hodinami a minutami umoţnila. Při nastavení komponenty provádí různé kontroly, aby nebylo například moţně nastavit, ţe den má 25 hodin apod.
Obrázek 27: Ukázka ovládacího prvku Time pro práci s hodinami a minutami
6.15 User Ovládací prvek má hned několik funkcí. Je pouţívám při registraci uţivatele, pouhém zobrazení informací o uţivateli, nebo editaci uţivatele. Takţe se musí podle typu pouţití přenastavit a zobrazit jiné ovládací prvky, které obsahuje. Například při registraci, kdy se
47
vyplňují informace o uţivateli, musí být funkční validátory kontrolující zda jsou hodnoty ve správném formátu. Oproti tomu se při pouhém zobrazení informací validátory vypínají apod. Jen pro ukázku zde uvedu obrázek ovládacího prvku v jednom reţimu (editace informací o uţivateli v nastavení profilu).
Obrázek 28: Ukázka ovládacího prvku User v reţimu editace uţivatele
48
7 Další funkce webové aplikace 7.1 Nastavení aplikace z konfiguračního souboru Technologie ASP.NET umoţňuje snadno umístit klíčové hodnoty aplikace, které nemohou být statické do konfiguračního souboru “web.config“. Do tohoto souboru se dá umístit opravdu velké mnoţství různých informací. Soubor je ve formátu XML a hlavní hodnoty pro nastavení aplikace jsou umístěny v bloku “appSettings“. Kaţdá poloţka je určena klíčem a její hodnotou. Např.:
Nastavitelné hodnoty:
ServerName - adresa serveru na kterém je aplikace umístěna BasicRateTax - sazba daně Currency - měna Culture - jazykové nastavení MaxFileSizeUpload - maximální velikost souboru pro upload v MB TargetDestinationFileUpload - univerzální umístění pro upload souborů smtp - název poštovního serveru ReceiverEmailWithErrors - e-mail příjemce chyb baseEmail - základní e-mail, od kterého budou chodit e-maily uţivatelům infoEmail - e-mail od kterého budou chodit e-maily uţivatelům registrace a pod. newsletterSender - odesílatel uvedený ve zpravodajích bccReceiver - skrytý příjemce pro příjem kopií registrací a pod.
Jednou z nejdůleţitějších vlastností, kde se přímo vybízí moţnost konfigurace, je nastavení připojovacího řetězce k databázi. Takzvaný “connectionString“. Uvedu zde jen jeden příklad zápisu, protoţe u něj můţete nastavit spoustu atributů.
49
7.2 Posílání e-mailů Pro odeslání e-mailů byla vytvořena speciální třída, která je napsána tak, aby byla snadno přenositelná do jiných aplikací. Proto jsem se snaţil jí napsat pro co moţná nejsnazší pouţití. Při posílání e-mailu je potřeba nastavit základní informace, jako je odesílatel, příjemce apod. Ovšem přidávat například příjemce jednoho po druhém není příliš rychlé řešení. Z toho důvodu jsem vytvořil vlastní třídu, která obsahuje dvě funkce a sama se stará o sestavení výsledného e-mailu. Pro ukázku zde popíši hlavičku jedné z nich. public static void Send( string to, // seznam příjemců oddělených čárkou nebo středníkem string from, // odesílatel string subject, // předmět e-mailu string body, // tělo e-mailu bool isHtml, // určuje zda je tělo e-mailu ve formátu HTML, nebo text string Bcc = null // skrytý příjemce e-mailu )
7.3 Zasílání chyb Webové aplikace v ASP.NET umoţňují při pádu aplikace zachytit vyvolanou vyjímku v metodě s názvem “Application_Error“, která je umístěná ve speciálním souboru “global.asax“. Toho vyuţívám k odeslání informačního e-mailu, abych věděl, ţe došlo k nějaké chybě a mohl ji následně opravit. Případně by bylo moţně vytvářet logovací soubor, protoţe kdyby byla nějaká chyba v poštovním serveru, neměli bychom ţádnou informaci o vzniklých chybách.
7.4 Zpravodaje Vzhledem k tomu, ţe se jedná o aplikaci určenou všem osobám a ne jen osobám uvnitř organizace. Přišlo mi vhodné přidat tento doplněk. Jedná se o vytváření článků, které procházejí schvalováním, aby se minimalizovala chybovost v textu. Tyto články jsou dále odesílány uţivatelům, kteří mají v osobním profilu zvolenou moţnost, ţe chtějí zasílat informace o novinkách. Tím můţeme snadno informovat uţivatele, kteří nenavštěvují web pravidelně, o novinkách a chystaných akcích.
50
8 Testování Testování aplikací patří k neoddělitelné části tvorby aplikací. Bez jakéhokoliv otestování by aplikace byla téměř nepouţitelná. K odhalení spousty chyb často dochází aţ po zavedení aplikace do ostrého provozu. Ačkoliv se to nezdá, samotné testování zabere více času neţ její programování, protoţe testování musíme provádět jiţ po částech při jejím programování. Pokud aplikaci testuje jen programátor, který ji píše, je pro něho velice obtíţné odhalit co nejvíce chyb, protoţe se vţdy při testování zaměřuje na specifické části, na které se jiné osoby programování neznalé nezaměří, a věřte, ţe dokáţí odhalit spousty chyb. Proto jsem se rozhodl aplikaci umístit na webový server http://vspjkonference.aspone.cz/ a poţádal několik přátel, aby webovou aplikaci otestovali. Jediný problém který nebyl vyřešen, se týkal přijímání e-mailů na serveru www.seznam.cz. Jiné portály nabízející práci s e-maily jako www.hotmail.com, nebo www.gmail.com neměli s příjmem e-mailů ţádný problém.
51
9 Závěr 9.1 Zhodnocení práce Cílem práce bylo vytvořit robustní aplikaci pro řízení odborných konferencí a seminářů pro VSPJ. Aplikace je umístěna na této adrese http://vspjkonference.aspone.cz/ a je funkční. Aplikace měla splňovat rozsáhlou funkcionalitu rozdělenou do uţivatelských rolí, čehoţ bylo docíleno. Při tvorbě bakalářské práce jsem se zaměřil na optimalizaci výkonu a návrhu pro co moţná nejsnadnější rozšíření o další funkcionalitu. Tudíţ jsem vyuţil objektového návrhu a oddělil grafickou stránku od aplikačního kódu. Asi nejsloţitějším úkolem bylo v aplikaci vytvořit podporu pro více jazyků (aktuálně čeština a angličtina), čehoţ jsem docílil slovníkem v bázi dat a vytvořením speciální třídy pro práci s těmito daty. Při návrhu slovníku jsem se snaţil zohlednit jeho snadné rozšíření o další jazyky. Vzhledem k tomu ţe se přeloţené texty vkládají dynamicky bez zásahu do programové části aplikace, můţe nastat problém při častém čtení dat ze slovníku a tím vytíţení databázového serveru (tato situace nemusí nikdy nastat, ale snaţil jsem se v bakalářské práci předcházet pozdějším problémům týkajících se výkonu). Pokud by takováto situace někdy nastala, bylo by zapotřebí rozšířit slovník o pomocné funkce, které by sníţily počet dotazů do databázového serveru. Pokoušel jsem se slovník urychlit pomocí vláken, ale zlepšení bylo minimální, protoţe databázový server (Microsoft SQL Server Express) nevyuţívá více jader procesoru. Ovšem pokud by databázový server běţel na vyšší verzi Microsoft SQL Serveru (jsou placené), mohlo by být zrychlení značné a nebylo by při větším vytíţení potřeba upravovat aplikační kód aplikace. Další problém pro mě byl grafický návrh vzhledu aplikace, jelikoţ nejsem moc graficky nadán. Pokusil jsem se vytvořit co moţná nejpřehlednější uţivatelské rozhraní, které nebude příliš náročné na přenos dat od serveru ke klientovi (především kvůli mobilním zařízením). V grafickém návrhu byly převáţně pouţity kaskádové styly, pomocí kterých je moţné grafický návrh značně modifikovat.
52
9.2 Možnosti dalšího rozšíření aplikace Mezi nejdůleţitější rozšíření bych zařadil statistiky ze všech moţných údajů, které jsou v mé práci k dispozici. Převáţně by se mělo jedna o přehledy návštěvnosti, plateb, výdajů a zisků za pořádané akce. Navrţení aplikace také umoţnuje snadno vyuţít uloţené informace ke kontrolám obsazeností místností a usnadnit tak plánování pořádaných akcí. Dalším rozšířením by mohlo být čtení došlých plateb z bankovního účtu pomocí sluţby běţící pod Windows a ve webové aplikaci tyto hotové platby označit za zaplacené, coţ by pořadatelům velice ulehčilo práci. S tím by bylo dále vhodné umoţnit uţivatelům provést zaplacení poplatků spojených s registrací pomocí platební karty. Samozřejmě ţe pro rozšiřování aplikace je spousta dalších moţností, ale rozšíření, které jsem víše popsal, by byly moţná vhodné i jako návrh pro další témata bakalářské práce. Posledním bodem bych chtěl zmínit různé tiskové sestavy, které nejsou v bakalářské práci obsaţeny, protoţe nevím, kde bude aplikace nakonec umístěna a zda bude vyuţívána. Pokud by k rozšiřování mé práce mělo dojít, doporučoval bych místo přímého tisku vyuţít sestavení dat do sešitů aplikace Excel (samotný export dat do sešitu aplikace Excel není sloţitý, ale je nutné, aby na stroji kde webová aplikace “běţí“, byla nainstalována patřičná verze Microsoft Office), který nabízí více moţností a v případě potřeby data snadno upravit. Přímý tisk z aplikace je spíše vhodný pro nějaké skladové systémy, či tisk faktur apod.
53
Seznam použité literatury [1]
STRAHL, Rick. West Wind Technologies [online]. 2007 [cit. 2011-05-30]. Setting up and running Subversion and Tortoise SVN. Dostupné z WWW: .
[2]
Http://www.microsoft.com [online]. 2011 [cit. 2011-05-30]. Produktová řada Microsoft Visual Studio 2010. Dostupné z WWW: .
[3]
Http://www.microsoft.com [online]. 2011 [cit. 2011-05-30]. Microsoft® SQL Server® 2008 Express with Tools. Dostupné z WWW: .
[4]
The Official Microsoft ASP.NET Site [online]. 2011 [cit. 2011-05-30]. Dostupné z WWW: .
[5]
Wikipedie [online]. 2011, 24. 5. 2011 [cit. 2011-05-30]. C Sharp. Dostupné z WWW: .
[6]
SNÍŢEK, Martin . CSS : pro zelenáče. Praha : Neocortex, 2003. 291 s. ISBN 8086330-14-1.
[7]
Wikipedie [online]. 2011, 25. 5. 2011 [cit. 2011-05-30]. LINQ. Dostupné z WWW: .
[8]
Wikipedie [online]. 2011, 3. 5. 2011 [cit. 2011-05-30]. JavaScript. Dostupné z WWW: .
[9]
ASP.NET AJAX Control Toolkit [online]. 2011 [cit. 2011-05-30]. ASP.NET AJAX Control Toolkit. Dostupné z WWW: .
[10]
CKEditor [online]. 2011 [cit. 2011-05-30]. Dostupné z WWW: . 54
[11]
MSDN [online]. 2011 [cit. 2011-05-30]. Introduction. Dostupné z WWW: .
[12]
HAKEN, Robert. ASP.NET : Vývoj webových aplikací ASP.NET [online]. 2011 [cit. 2011-05-30]. Lokalizace snadno a rychle - explicitní lokalizace . Dostupné z WWW: .
[13]
CHINNATHAMPI, Jesudas. Asp alliance [online]. 2011 [cit. 2011-05-30]. Building AJAX Enabled File Uploading System with Progress Bar Using ASP.NET 2.0. Dostupné z WWW: .
[14]
Lorem Ipsum [online]. 2011 [cit. 2011-05-30]. Dostupné z WWW: .
55
Seznam obrázků Obrázek 1: Úvodní stránka portálu ....................................................................................... 16 Obrázek 2: Ukázka ze stránky s nastavením cen konference a událostí v konferenci .......... 19 Obrázek 3: Ukázka druhé úrovně poloţek v menu ............................................................... 20 Obrázek 4: Ukázka stromové struktury poloţek v menu aplikace ....................................... 21 Obrázek 5: Základní dělení webových stránek ..................................................................... 23 Obrázek 6: Administrace článků........................................................................................... 24 Obrázek 7: Pomocné menu vyuţívající články..................................................................... 24 Obrázek 8: Administrace článků pro úvodní stránku ........................................................... 25 Obrázek 9: Editace příspěvku ............................................................................................... 27 Obrázek 10: Formulář pro schvalování příspěvků ................................................................ 28 Obrázek 11: Ukázka administrace místa konání................................................................... 29 Obrázek 12: Ukázka návrhu modulů pro místa konání v datové vrstvě ............................... 29 Obrázek 13: Ukázka formuláře v administraci semináře...................................................... 30 Obrázek 14: Ukázka kontrolu pro modul Platby/Účast pro administrátora .......................... 32 Obrázek 15: Ukázka stránky pro práci se zpravodaji ........................................................... 33 Obrázek 16: Struktura tabulky slovníku v bázi dat............................................................... 34 Obrázek 17: Třídy pro práci se slovníkem............................................................................ 34 Obrázek 18: Ukázka stránky pro vytvoření překladů s WYSIWYG editorem ..................... 35 Obrázek 19: Ukázka resources v projektu ............................................................................ 36 Obrázek 20: Ukázka obsahu zdrojového souboru (resources) pro lokalizaci aplikace ........ 37 Obrázek 21: Základní diagram třívrstvé architektury webové aplikace ............................... 38 Obrázek 22: Rozloţení třívrstvé architektury ve Visual Studiu ........................................... 39 Obrázek 23: Ukázka ovládacího prvku CommandToolbar v reţimu SelectedConference .. 41 Obrázek 24: Ukázka ovládacího prvku FileUpload pro nahrávání souborů na server ......... 43 56
Obrázek 25: Ukázka ovládacího prvku PageControl pro vytvoření/editaci stránek ............. 44 Obrázek 26: Ukázka ovládacího prvku SiteMapPath znázorňujícího zanoření stránky ....... 47 Obrázek 27: Ukázka ovládacího prvku Time pro práci s hodinami a minutami .................. 47 Obrázek 28: Ukázka ovládacího prvku User v reţimu editace uţivatele ............................. 48
57
Seznam zkratek .NET – “dot net“ zkratka z NETWORK Ajax – Asynchronous Javascript And Xml ASP.NET – Active Server Pages s .NET CSS – Cascading Style Sheets HTML – Hypertext Transfer Protocol IIS – Internet Information Services LINQ – Language Integrated Query MD5 – Message-Digest Algorithm PDF – Portable Document Format SHA-1 – Secure Hash Algorithm SQL – Structured Query Language UML – Unified Modeling Language WYSIWYG – What you see is what you get XML – eXtensible Markup Language
58
Seznam příloh A
Diagram modulů a třívrstvé architektury
B
Diagram tříd logické vrstvy
C
Relační model báze dat
D
Zdrojové kódy aplikace
E
CREATE SCRIPT a INSERT SCRIPT pro vytvoření báze dat
59
