Online rozřazovací test z angličtiny

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY

BAKALÁŘSKÁ PRÁCE

Online rozřazovací test z angličtiny

2010

Michal Utíkal

Anotace Cílem práce je implementovat webovou aplikaci pro rozřazovací test z angličtiny pro studenty prvních ročníků PřF UP. Test bude sloužit ke zjištění pokročilosti studentů v angličtině a jejich zařazení do skupiny.

Chtěl bych poděkovat všem kolegům za jejich cenné připomínky při tvorbě aplikace a zvláště pak vedoucímu práce Michalu Krupkovi za jeho čas a pomoc. Díky patří také Kabinetu cizích jazyků za možnost podílet se na tomto projektu.

Obsah 1. Zadání 1.1. Specifikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Určení problémové domény . . . . . . . . . . . . . . . . . . . . . . 1.3. Základní požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Úvod do problematiky 2.1. World Wide Web . . . . . . . . . . . . . 2.2. Historie, současnost a budoucnost . . . . 2.2.1. Historie . . . . . . . . . . . . . . 2.2.2. Současnost . . . . . . . . . . . . . 2.2.3. Budoucnost . . . . . . . . . . . . 2.3. Architektura webu . . . . . . . . . . . . 2.4. Webové inženýrství . . . . . . . . . . . . 2.5. Webové technologie . . . . . . . . . . . . 2.5.1. Technologie popisující dokumenty 2.5.2. Klientské technologie . . . . . . . 2.5.3. Serverové technologie . . . . . . . 3. Analýza 3.1. PHP . . . . . . . . . . . . . . . . . 3.2. Java . . . . . . . . . . . . . . . . . 3.3. ASP.NET . . . . . . . . . . . . . . 3.3.1. ASP.NET Web Forms . . . 3.3.2. ASP.NET MVC Framework

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

7 7 7 7

. . . . . . . . . . .

8 8 8 8 9 9 10 11 13 13 14 15

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

16 16 18 19 20 21

4. Uživatelská příručka 4.1. Struktura aplikace . . . . . . . . . . . . . 4.2. Nepřihlášený uživatel . . . . . . . . . . . . 4.3. Přihlášený uživatel - student . . . . . . . . 4.3.1. Seznam testů - student . . . . . . . 4.3.2. Zobrazení testu - student . . . . . . 4.3.3. Spuštění testu . . . . . . . . . . . . 4.3.4. Zobrazení výsledku testu - student 4.4. Přihlášený uživatel - administrátor . . . . 4.4.1. Seznam testů - administrátor . . . 4.4.2. Zobrazení testu - administrátor . . 4.4.3. Editace testu . . . . . . . . . . . . 4.4.4. Statistiky . . . . . . . . . . . . . . 4.4.5. Vizualizace . . . . . . . . . . . . . 4.4.6. Sitemap . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

22 22 22 23 23 24 25 25 26 26 27 27 29 31 32

4

. . . . .

. . . . .

. . . . .

5. Programátorská příručka 5.1. Požadavky na nasazení . . . . . 5.2. Architektura aplikace . . . . . . 5.3. Hlavní třídy . . . . . . . . . . . 5.4. Programátorské API . . . . . . 5.4.1. Tests Controller . . . . . 5.4.2. Statistics Controller . . . 5.4.3. Account Controller . . . 5.5. Typické problémy a jejich řešení 5.6. Klientské technologie . . . . . . 5.7. Volba datového modelu . . . . . 5.8. Grafické zpracování . . . . . . . 5.9. Metodologie vývoje . . . . . . . 5.10. Správa verzí a řízení projektu . 5.11. Logování chyb . . . . . . . . . . 5.12. Ladění . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

33 33 33 34 34 34 35 36 36 37 37 37 38 39 39 39

Závěr

40

Conclusions

41

Reference

42

5

Seznam obrázků 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Struktura aplikace. . . . . . . . . . . . . . . . . Nepřihlášený uživatel. . . . . . . . . . . . . . . Menu - student. . . . . . . . . . . . . . . . . . . Seznam testů - student. . . . . . . . . . . . . . . Informace o testu a povinný dotazník. . . . . . . Spuštěný test. . . . . . . . . . . . . . . . . . . . Celkové hodnocení, doporučení dalšího postupu mětů studenta. . . . . . . . . . . . . . . . . . . Menu - administrátor. . . . . . . . . . . . . . . Seznam testů - administrátor. . . . . . . . . . . Zobrazení testu - administrátor. . . . . . . . . . Editace testu. . . . . . . . . . . . . . . . . . . . Statistika testů. . . . . . . . . . . . . . . . . . . Zobrazení výsledku testu - administrátor. . . . . Vizualizace výsledků testů. . . . . . . . . . . . . Navigace v aplikaci. . . . . . . . . . . . . . . . .

6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a seznam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . před. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 23 23 24 24 25 26 27 27 28 29 30 31 32 33

1.

Zadání

1.1.

Specifikace

Cílem práce je implementovat webovou aplikaci pro rozřazovací test z angličtiny pro studenty prvních ročníků PřF UP. Test bude sloužit k zjištění pokročilosti studentů v angličtině a jejich zařazení do skupiny. Studentům bude v den zápisu předána informace, kde a do kdy mají možnost elektronický test vyplnit. Protože v té době již budou mít přihlašovací údaje do stagu, bude jejich identita částěčně ověřena podle jejich osobního čísla stagu. Po úspěšném přihlášení a vyplnění povinných údajů, může student začít vyplňovat příslušný test. Na vyplnění testu má časový limit 30 minut a test je možné odeslat pouze jednou. Po odeslání testu je studentovi zobrazen jeho výsledek, slovní hodnocení a seznam jeho povinných a volitelných předmětů angličtiny. Odeslané testy se v aplikaci ukládají a vyučující má kdykoliv možnost zpětně si zobrazit výsledek libovolného studenta. S těmito výsledky jde dále manipulovat a je možné je exportovat pro další použití. Vyučující má také přístup ke grafickým statistikám celkových výsledků testů a k editaci testů.

1.2.

Určení problémové domény

Nová aplikace má nahradit stávající systém rozřazovacích testů Kabinetu cizích jazyků Přírodovědecké fakulty Univerzity Palackého. V současné době probíhá testování studentů v den zápisu absolvováním prezenčního testu na papír a jeho následném ohodnocení odpovědnými vyučujícími. Toto řešení spoléhá na přítomnost studenta na testu a klade vysoké nároky na čas vyučujícího.

1.3.

Základní požadavky

• Rozhraní pro vyplnění testů. • Možnost editace testů. • Vyhodnocení výsledků. • Export výsledků testů pro další zpracování. • Aplikace bude přizpůsobena i dalším požadavkům získávaným průběžně od konzultanta. • Součástí práce bude analýza a porovnání technologií použitelných na implementaci aplikace a zdůvodnění jejich volby.

7

2.

Úvod do problematiky

Úvodní kapitola nejprve stručně popisuje historický kontext vývoje oboru. Pochopení historického vývoje je nezbytné pro plánování vývoje budoucího. Dále je popsána architektura Webu a obor který se jím zabývá. Jako poslední jsou popsány dostupné technologie pro vývoj webových aplikací.

2.1.

World Wide Web

Mezi mnoha službami zavedenými po vzniku Internetu 1 byla i služba World Wide Web (WWW, krátce Web). Jedná se o systém propojených hypertextových dokumentů, které lze prohlížet díky webovému prohlížeči 2 .

2.2. 2.2.1.

Historie, současnost a budoucnost Historie

Dějiny Webu3 začaly roku 1989 kdy se Angličan Tim Berners-Lee aktuálně zdržoval v Evropské laboratoři jaderné fyziky (CERN) v Ženevě[10]. Plán pro World Wide Web –jak ho pojmenoval –se orientoval na vyvinutí nástroje, pomocí kterého by si mohla pohodlnou cestou vyměňovat data a myšlenky celosvětově roztroušená obec fyziků CERN. Téhož roku byla dokončena specifikace HyperText Markup Language (HTML), sloužících k zápisu dokumentů přenášených pomocí protokolu HyperText Transmission Protocol (HTTP). Díky tomuto hypertextu bylo možné navádět uživatele od jednoho dokumentu k jinému, aniž by k tomu byly zapotřebí složité příkazy. Aby uživatel dostal dokumenty ze vzdálených serverů a aby byly čitelné, byl potřebný jen pomocný program –browser. Koncem roku 1990 byl vytvořen první prototyp systému WWW na počítačích NeXT ve středisku CERN a obsahoval webový prohlížeč pojmenovaný WorldWideWeb, specifikaci jazyka HTML a webový server4 . Další osudné rozhodnutí padlo roku 1993, kdy CERN oznámil, že nebude požadovat za technologii WWW žádné poplatky za využití patentu a copyrightu. Tím 1

Internet je celosvětový systém navzájem propojených počítačových sítí, ve kterých mezi sebou počítače komunikují pomocí rodiny protokolů TCP/IP, http://cs.wikipedia.org/wiki/internet 2 Webový prohlížeč je softwarová aplikace pro získávání, prezentování a procházení zdrojů na Webu. 3 pozn. autor –Web 1.0 4 Webový server je počítačový program, který na základě klientských požadavků vrací odpovídající webové zdroje.

8

se otevřela cesta pro celosvětové zavedení do užívání. Ve stejné době také americká firma Network Solutions přebírá úkol spravovat adresový prostor, tzv.Top Level Domains –např. .com, .net, .org a .edu5 . 2.2.2.

Současnost

Za dvacet let své existence se Web stal celosvětovým fenoménem. Jeho rychlé rozšíření a extrémní vývoj měly za následek změny v povaze jeho používání. Z dřívějších statických stránek se postupně vyvinuly stránky dynamické, schopné měnit svůj obsah interakcí s uživatelem. Pro novou generaci webových stránek byl zaveden termín Web 2.0 6 . Web 2.0 jsou běžně označovány webové aplikace, které umožňují interaktivní sdílení informací, součinnost, uživatelsky zaměřený design a spolupráci na Webu. Stránky vytvořené v duchu Web 2.0 umožňují uživatelům vzájemně komunikovat přispíváním k obsahu webové stránky, narozdíl od původních statických stránek, které sloužily pouze k zobrazování informací. Příklady Web 2.0 stránek mohou být aplikace webových komunit, sociální sítě, stránky sdílející video, wikipedie a blogy. Přísně vzato však tento termín neznamená nový update nebo technickou specifikaci, ale jde pouze o kumulativní změny použití Webu programátory a uživateli. 2.2.3.

Budoucnost

Do blízké budoucnosti patří Web 3.0 –co z něj vzejde zatím není jisté, nicméně jednou z jeho částí může být i sémantický web 7 . V sémantickém webu je definován význam (sémantika) informací tak, aby bylo možné tyto informace strojově zpracovávat. Narozdíl od Webu dokumentů (Web složený z nestrukturovaných textových informací) se tedy jedná o Web dat (text jsou data). Standardizaci Webu se věnuje W3C konzorcium 8 . Vice-prezident firmy Google, vizionář a ”otec internetu” Vint Cerf [11] shrnul na jedné ze svých konferencí Future of Global Web Technology situaci následovně: V roce 1997 bylo 50 miliónů uživatelů internetu a do roku 2007 jejich počet vzrostl na 1 244 mil., z celkového počtu 6.5 miliardy obyvatel na této planetě. To znamená, že více než 5 miliard obyvatel teprve přijde do kontaktu s internetem a odhaduje se, že většina z nich se připojí přes nějaké mobilní zařízení. Největší internetová komunita se již nyní nachází v Asii (459.5 miliónu, pokryto 12,4% obyvatel), následuje Evropa (337.9 miliónu, pokryto 41,7% obyvatel). 5 Domain Name System (DNS) je jmenná služba Internetu, zajišťující překlad jmen prostředků na síti na IP-adresy a naopak. 6 http://en.wikipedia.org/wiki/web 2.0 7 http://www.w3.org/standards/semanticweb/ 8 World Wide Web Consortium je mezinárodní standardizační organizace pro World Wide Web, http://www.w3.org

9

Data přesvědčivě hovoří o potenciálu asijského regionu k expanzi a o tom, že nová generace webových aplikací přijde z Asie (dříve USA, Evropa). Stejně tak dojde k podstatnému nárůstu zařízení připojených k internetu, a to bude v roce 2035 ve vyspělých státech činit až deset zařízení na jednoho člověka (mobilní telefon, televize, gadget stations, playstation, lednička, . . .). Význam internetu do budoucna poroste v důsledku nárůstu populace (v roce 2035 byl odhad populace stanoven na 10.5 miliardy) a zvyšující se ceny dopravy (globální oteplování, nedostatek ropy, uhlí a plynu), a také zlevnění cen energie potřebné ke komunikaci přes síť (např. video hovory, dálkově ovládaný robot, . . .). Mezi výzvy, kterým budeme v budoucnu čelit patří otázky distribučních práv dokumentů, vyhledávání podle významu, nikoli podle čistého textu, kompatibilita (budeme mít dokumenty, ale ne už programy k jejich otevření) –otevřené formáty,vyhledávání podle lokality –geoinformatika. Navíc již nyní se úspěšně testují meziplanetární protokoly nové generace.

2.3.

Architektura webu

Architektura Webu je navržena podle pravidel Representational State Transfer (REST9 ), přestože tato pravidla byla zformulována až dlouho po Webu samotném. REST je styl softwarové architektury pro distribuované hypermediální systémy. Architektura REST se skládá z klientů a serverů. Klient pošle požadavek na server, server požadavek zpracuje a vrátí odpovídající odpověď. Požadavky a odpovědi odpovídají transferům reprezentací zdrojů. Zdroje mohou být jakékoliv smysluplné elementy, které lze jednoznačně adresovat. Reprezentace zdroje je typicky dokument, který zachycuje stav zdroje. Klient může v každou chvíli buď přecházet mezi jednotlivými stavy aplikace nebo být v klidu (”at rest”). Klient, který je v klidu může používat data aniž by spotřebovával prostředky serveru nebo sítě. Klient začne zasílat požadavky, když je připraven změnit stav. Pokud není jeden nebo více požadavků obslouženo, klient se nachází v jednom z přechodných stavů. Reprezentace každého stavu obsahuje odkazy, které mohou být použity příště pro zaslání nového požadavku o změnu stavu. REST architektura byla vyvinuta společně s protokolem HTTP/1.1. Každou aplikaci, která splňuje následující omezení můžeme označit RESTful : • Klient-server - Klient je oddělen od serveru jednotným rozhraním. Server se nezajímá o přístupové prostředí uživatele ani o jeho aktuální stav, což vede k jednodušší implementaci a škálovatelnosti serveru. Pokud zůstane rozhraní nezměněno, klient i server mohou být nahrazeny nezávisle na sobě. 9

http://en.wikipedia.org/wiki/representational state transfer

10

• Bezstavovost - Komunikace mezi klientem a serverem je omezena tím, že na serveru není mezi dvěma požadavky uložený žádný kontext uživatele. Každý požadavek uživatele obsahuje všechny potřebné informace nutné k obsloužení požadavku. Server může obsahovat stav pouze tehdy, pokud je (stav) adresovatelný pomocí URL10 zdroje. • Cache - Klienti si mohou ukládat odpovědi na jejich požadavky do cache 11 . Každá odpověď musí obsahovat informace o tom, jestli je cachovatelná, aby povolila znovupoužívání stavu uživatele. • Vrstevná architektura - Klient nemůže určit jestli je připojen přímo ke koncovému serveru nebo nějakému zprostředkovateli. Zprostředkovatelé mohou sloužit k rozdělovnání zátěže nebo sdílenému cachování. • Kód na požádání (volitelný) - Server může na požádání rozšířit nebo upravit funkcionalitu klienta přenesením logiky aplikace na jeho stranu. Toto platí například pro kompilované komponenty nebo klientské skripty. • Jednotné rozhraní - Jednotné rozhraní zjednodušuje architekturu a umožňuje měnit nezávisle jednotlivé části. S webovými aplikacemi uživatel pracuje skrz webový prohlížeč. Po zadání jednoznačného URL se uživateli jako odpověď na jeho požadavek zobrazí HTML stránka vygenerovaná na straně serveru a přenesená na klientskou stanici pomocí protokolu HTTP. Pro tuto stránku navíc existuje standard W3C pro jednotnou podobu jejího formátu. Webové aplikace ke svému provozu využívají služeb hostujících serverových počítačů. Ty jsou umístěny někde v síti a uživatel k nim může přistupovat z libovolné stanice připojené k Internetu.

2.4.

Webové inženýrství

Webové inženýrství je aplikace systematických, řízených a meřitelných postupů pro vývoj, vykonávání a údržbu webově orientovaných aplikací[1]. Jedná se o multidisciplinární obor, který vznikl jako odpověď na dřívější chaotický vývoj v rychle se měnící oblasti vývoje webových aplikací. Z různých úhlů pohledu může být webové inženýrství chápáno jako soubor následujících dovedností: • Konstrukce a návrh webových stránek - Základní stavební prvky www jsou webové stránky. Jedná se o dokumenty skládající se z elementů nějakého 10 Url Resource Locator je řetězec znaků s definovanou strukturou, který slouží k přesné specifikaci umístění zdrojů informací na Internetu. 11 Cache je komponenta, která zlepšuje výkon aplikací ukládáním dat tak, aby při přístím požadavku mohly být obslouženy rychleji.

11

značkovacího jazyka (např. HTML). Protože ke konstrukci webové stránky není zapotřebí znalosti žádného programovacího jazyka, je tato část otevřená i poměrně laické veřejnosti. Obojí konstrukce i návrh webové stránky je disciplína, která víceméně spadá do oborů zabývajících se problematikou uživatelských rozhraní. • Konstrukce a návrh webové aplikace - Hypertextovým propojením více webových stránek vznikají webové aplikace. Navigaci mezi jednotlivými stránkami umožňují data popisující aplikaci –metadata[2]. • Webové systémy - Jedná se o soubor webových aplikací vzájemně kooperujících za určitým cílem. • Plánování a management webových projektů - Mezi základní problémy vývoje libovolných aplikací patří nedodržení termínu, ceny a kvality. Pochopení důležitosti všech fází vývoje webových aplikací je nezbytné k jejich minimalizaci a ušetření tak nákladů při možných opravách nefunkčního software. Proto je zřejmá potřeba systematického, měřitelného a opakovatelného procesu vývoje webových aplikací. Z výše zmíněného je zřejmé, že k popisu všech problémů vývoje webových aplikací nestačí Softwarové inženýrství, které se jako obor převážně zabývá vývojem desktopových aplikací. Pokusme se tedy shrnout některé rozdíly mezi webovými a desktopovými aplikacemi. • Udržovatelnost - Webovou aplikaci stačí naistalovat na jeden speciální počítač, zatímco desktopové aplikace je potřeba instalovat zvlášť pro každou pracovní stanici a týká se to i jejich aktualizací a údržby. • Použitelnost - Desktopovou aplikaci lze využívat pouze na stanici, na které je nainstalována a běží přímo v paměti klientského počítače. To velmi zrychluje běh aplikace a umožňuje naplno využívat potenciál moderního hardwaru. Na druhou stranu webové aplikace lze používat odkudkoliv, kde je připojení k Internetu. • Bezpečnost - Webové aplikace nesou potenciálně větší bezpečnostní rizika plynoucí z nechráněné komunikace, která jsou pro desktopové aplikace na lokálním stroji podstatně menší. • Připojení k síti - Webové aplikace jsou závislé na připojení k Internetu a jeho absence nebo pomalá rychlost se projevuje v kvalitativních problémech při práci s aplikací. Tím, že desktopové aplikace ke svému běhu nepotřebují připojení k Internetu, nedochází k prodlevám při vyřizování požadavků nebo jiným chybám síťové komunikace. Samozřejmě není možné toto rozdělení brát dogmaticky, protože existují webové aplikace, které běží pouze 12

na lokálním stroji a desktopové aplikace, které ke svému provozu používají síťovou komunikaci. • Cena - Desktopová aplikace je zakoupena jednou a neobsahuje další poplatky. Cena vývoje a udržování webových aplikací se většinou skládá z opakovaných poplatků, a proto je často nákladnější. • Další perspektivy - Na rozdíl od HTML stránky, která je typicky výstupem webové aplikace a jejíž struktura má standardizovanou podobu, se standardy pro vytváření desktopových aplikací liší v závislosti na použité platformě. Desktopové aplikace na platformách Mac a Windows tedy budou vypadat různě, zatímco HTML stránka bude v ideálním případě identická napříč spektrem operačních systému a webových prohlížečů. V minulosti pracovaly informační systémy převážně s transakčně zpracovatelnými numerickými daty s minimem textových informací. Dnešní webově orientované informační systémy naopak obsahují mimo jiné text a multimédia, která jsou obtížně strukturovatelná, nemohou být normalizována a nelze je třídit a vyhledávat v nich. Vznikají v nich nejenom problémy s vlastnictvím obsahu, ale i další legální, etické a sociální problémy. Takové problémy dříve nebylo potřeba řešit, ale při vývoji webových aplikací je k nim potřeba přihlédnout. Protože webové aplikace jsou vystaveny uživatelům z celého světa, musí být vytvořena strategie a politika jejich užívání pro uživatele potenciální i neznámé tak, aby byly zajištěny kvalitní služby a spokojenost zákazníků. Webové aplikace jsou multidisciplinárním oborem. Jsou vyvíjeny v konstantně měnícím se prostředí a s nestálými požadavky zákazníků. Vývojové týmy jsou typicky malé, naopak uživatelská komunita je větší než kdy dříve. Kvalitní webové aplikace musí být použitelné, funkční, spolehlivé, udržovatelné, škálovatelné a bezpečné, a proto existuje obor Webové inženýrství, který se těmito problémy zabývá.

2.5.

Webové technologie

V následujícím rozboru[3] si stručně rozebereme různé technologie podle doporučení organizace W3C: 2.5.1.

Technologie popisující dokumenty

• HTML - Hypertext Markup Language vychází z jazyka SGML a popisuje elementy, které mohou být použity k označení obsahu hypertextových dokumentů. Pro tyto elementy také určuje jejich vzájemné vztahy, sémantiku a syntaxi. Každý element je uzavřen pomocí symbolů ”menší” a ”větší”.

13

• SVG (Scalable Vector Graphics) - Je formát popisující grafiku v XML. Obsahuje objekty třech typů –vektory (linky a křivky), obrázky a text. Grafické objekty mohou být seskupeny do jiných objektů. • SMIL (Synchronized Multimedia Integration Language) - Tento standard byl vyvinut pro synchronizované multimediální prezentace. Umožňuje řízení prezentace různých médii jako zvuku, textu a obrázků. Každému mediu je možné nastavit čas a umístění akce. • XML (eXtensible Markup Language) - XML je dalším populárním dialektem SGML. Jedná se o rozšiřitelný a obecný značkovací jazyk, který umožňuje snadné vytváření konktrétních značkovacích jazyků pro různé účely a různé typy dat. Jazyk je určen především pro výměnu dat mezi aplikacemi, serializaci dat a jejich validaci. • XSL (eXtensible Stylesheet Language) - XSL je soubor tří jazyků pro transformaci a zobrazování XML dokumentů: 1. XSL Transformations - Jazyk pro transformování XML dokumentů. 2. XPath - Jazyk pro adresování částí XML dokumentů. 3. XSL-FO - Jazyk pro určení vizuálního formátování XML dokumentů. 2.5.2.

Klientské technologie

• Pomocné programy a pluginy - Pomocné programy přidávají funkcionalitu webovým prohlížečům. Potom co prohlížeč dostane jako odpověď na klientský požadavek data asociovaná s některým pomocným programem nebo pluginem, jsou tato data přesměrována ke zpracování tímto externím programem. Pomocný program musí být nainstalován na klientský počítač. Plugin je speciální typ pomocného programu a je nainstalován přímo do webového prohlížeče. • Java applety - Java applety jsou programy napsané v jazyce Java, které se dynamicky načítají do prohlížeče. Kvůli bezpečnosti nemají přístup ke všem systémovým zdrojům a říkáme, že běží v tzv. sandboxu. • ActiveX prvky - ActiveX12 je framework pro definování znovupoužitelných softwarových komponent v libovolných programovacích jazycích. Softwarové aplikace mohou být složeny z jedné nebo více těchto komponent. Tato technologie byla zavedena v roce 1996 firmou Microsoft pro rozšíření svých technologií Component Object Model (COM) a Object Linking and Embedding (OLE). Prvky ActiveX běží pouze v prohlížeči Internet Explorer na 12

http://en.wikipedia.org/wiki/activex

14

platformě Windows. Protože mají velká systémová oprávnění, jejich spouštění má bezpečnostní rizika. • Skriptovací jazyky - Skriptovací jazyky rozšiřují funkcionalitu prohlížeče zejména o dynamické efekty. Mezi klientské skriptovací jazyky patří populární jazyk Javascript. 2.5.3.

Serverové technologie

• SSI (Server-Side Includes) - Je jednoduchý interpretovaný skriptovací jazyk na straně serveru. Jeho nejčastější použití je pro vkládání jednoho nebo více souborů do webové stránky. Pro vykonání těchto souborů se vsuvkami SSI je potřeba, aby soubor měl některou z následujících koncovek: .shtml, .stm nebo .shtm. • CGI/FastCGI - The Common Gateway Interface (CGI) je standard definující, jak může webový server delegovat generování webových stránek konzolové aplikaci. Tyto aplikace mohou být napsány v libovolném jazyce, ale často se jedná o jazyky skriptovací. Když webový server identifikuje požadavek od klienta, zavolá odpovídající spustitelný soubor a předá mu parametry. Protože při každém požadavku je v paměti serveru vytvořena nová instance CGI skriptu, jejich vykonávání je značně neefektivní. • Skriptovací jazyky - Mezi skriptovací jazyky na straně serveru patří jazyky ASP, PHP, Cold Fusion a serverový JavaScript. Příkazy těchto jazyků se zapisují přímo do HTML kódu pomocí vsuvek a jsou vykonány před zasláním odpovědi klientovi. • ASP.NET - Je technologie platformy Microsoft .NET Framework, umožňující psát aplikace v libovolném jazyce podporujícím běhový režim Common Language Runtime (CLR). Stejně jako v případě jazyka Java se nejdříve kompiluje na bytekód nazývaný Microsoft Intermediate Language (MSIL) a dále potom podle potřeby na strojový kód. Aplikace takto napsané mají podobné výkonové vlastnosti jako aplikace napsané například v jazyce C++. Aby se šetřilo systémovými zdroji, je celé ASP.NET implementováno jako ISAPI rozhraní. To dovoluje aplikaci zkompilovanou do jediné knihovny Dynamic Linked Library (DLL) nahrávat do stejného paměťového prostoru jako webový server při prvním požadavku. Každý další požadavek je pak už jen rychle obsloužen z této paměti, a tím odpadá opětovné zatěžování serveru jako u instancí CGI. • JavaServer Pages (JSP) - Je technologie pro dynamické generování webových stránek. Byla vytvořena v roce 1999 firmou Sun Microsystems jako odpověď na konkurenční technologie ASP a PHP. JSP stránky jsou při 15

prvním načtení přeloženy na Java servlety, které poté již obsluhují všechny následující požadavky. Tato technologie je multiplatformní, protože dokáže běžet na každém serveru, který má nainstalovanou podporu Java Virtual Machine (JVM). • Webové služby13 - Jsou softwarové systémy navržené pro podporu komunikace počítač-počítač po síti. Mají rozhraní v počítačově zpracovatelném formátu Web Services Description Language (WSDL). Ostatní systémy komunikují s webovými službami zprávami, které jsou realizovány pomocí HTTP, XML serializace a ostatních webových standardů. Existují dva druhy webových služeb: Webové služby odpovídající specifikaci REST, které jsou bezstavové a jejichž účelem je manipulace s XML reprezentacemi webových zdrojů a webové služby, které po síti zpřístupňují množinu základních operací serveru. Mezi zástupce webových služeb patří technologie Service-Oriented Architecture (SOAP), Remote Procedure Calls (RPC) a Representational State Transfer (REST).

3.

Analýza

Validované základní požadavky získané přímo od klienta v první fázi projektu sloužily jako podklad pro další analytické práce. V praxi by jejich produktem byl dokument SRS14 , jednoznačně určující podobu a rozsah zakázky. Tento dokument je výchozí a klíčový pro navazující fáze. Mezi tyto další fáze patří volba vhodné metodologie vývoje softwaru, odhad nákladů, plánování testování a nasazení aplikace. Důkladná počáteční analýza také šetří budoucí náklady na opravu softwaru, které prudce rostou s časovým postupem projektu. Analytická fáze[7] spočívala v analýze požadavků vzhledem k možnostem nejmodernějších technologií. Kromě požadavků daných klientem byly brány v potaz obecné cíle projektu, jeho potenciální uživatelé, jejich množství a oprávnění. V následujícím textu si stručně popíšeme tři nejpoužívanější technologie pro generování stránek na straně serveru. Tato analýza mimo jiné vychází i z osobních zkušeností autora s programováním v těchto technologiích.

3.1.

PHP

Personal Home Page (PHP)15 je skriptovací programovací jazyk určený především pro programování dynamických webových stránek. Vznikl v roce 1994 a 13

http://en.wikipedia.org/wiki/web service Software Requirements Specification 15 http://cs.wikipedia.org/wiki/php 14

16

následujícího roku byl vydán pro užívání veřejnosti. Pro generování kódu používá vsuvky, které se vkládají přímo do HTML dokumentů a jsou zpracovány na straně serveru, ještě před odesláním odpovědi klientovi. Syntaxe jazyka je inspirována několika programovacími jazyky: Perl, C, Pascal a Java. Je to dynamicky typovaný jazyk. Jazyk PHP se stal díky své jednoduchosti nejrozšířenějším jazykem webových technologií vůbec. Jedná se o jazyk interpretovaný, původně neobjektový a nerozlišující důsledně vrstvy podle tradiční třívrstvé architektury. Mnoho z těchto a dalších nedostatků bylo postupně opraveno, buď přímo v jazyce samotném nebo pomocí knihoven třetích stran. Nejčastěji se používá v kombinaci s operačním systémem Linux, databázovým systémem MySQL a webovým serverem Apache. Výhody • PHP je specializovaný na tvorbu webových stránek. • Obsahuje rozsáhlý soubor funkcí v základní knihovně. • Nativní podpora mnoha databázových systémů. • Multiplatformost (Zejména Linux a Windows). • Strmá křivka učení. • Podpora na webhostingových službách. • Množství volně dostupných projektů a kódů. • Slušná dokumentace. • Velmi svobodná licence. Nevýhody • Jazyk PHP není nikde definován, je popsán pouze svou implementací. • Nekonzistentní pojmenování funkcí i jejich skupin. • Špatná podpora vyjímek. • Slabší podpora Unicode, pouze přes knihovnu PHP. • Ve standardní distribuci chybí ladicí nástroj. • Pro zpracování požadavku neudržuje kontext aplikace a musí jej tedy pokaždé vytvářet znovu. 17

• Není to komerční jazyk, nikdo nezodpovídá za kvalitu technického řešení. Přestože je možné použít mnoho knihoven třetích stran, jejich kvalita může být různá. • Nerozlišuje vrstevnou architekturu aplikace a programátor si ji buď musí naprogramovat sám nebo použít nějakou dostupnou. • Samotný jazyk programátora nenutí dodržovat praktiky kvalitního programování, často potom vzniká nekvalitní zdrojový kód. • Jazyk nepodporuje standardní programové prostředky jako vlákna a knihovny. • Knihovny jazyka je často potřeba instalovat na webový server, což způsobuje špatnou přenositelnost a problémové nasazení na produkční server. • PHP je interpretovaný jazyk, to značně snižuje jeho výkon. • Nezachovává zpětnou kompatibilitu mezi verzemi jazyka.

3.2.

Java

Java je programovací jazyk vytvořený Jamesem Goslingem z firmy Sun Microsystems a byl vydán v roce 1995 jako součást Java platformy16 . Syntaxe jazyka je odvozena z jazyka C a C++, ale má jednodušší objektový model a méně nízko-úrovňových prvků. Díky své přenositelnosti a objektové orientaci se stala jedním z nejpoužívanějších programovacích jazyků vůbec, nejenom pro webové technologie. Při jeho kompilaci nejprve dochází k vytvoření bajtkódu, který může běžet na libovolné stroji, na kterém je nainstalována Java Virtual Machine (JVM). Java je víceúčelový jazyk založený na třídách a objektovém paradigmatu programování (OOP) a je speciálně navržen, aby měl co nejméně implementačních závislostí. Java je jedním z nejdůležitějších jazyků dvacátého století. Výhody • Jednoduchý, objektový jazyk se spoustou dostupných frameworků. • Robustnost a bezpečnost. • Implementační nezávislost. • Výkon. • Automatická správa paměti. 16

http://en.wikipedia.org/wiki/java (programming language)

18

Nevýhody • Samotný jazyk neobsahuje nejmodernější knihovny, ty je potřeba získat externě. • Nemá jednotné vývojové prostředí a přenos projektů mezi více vývojovými prostředími je složitý nebo v případě GUI aplikací nemožný. • Jazyk díky historickému vývoji obsahuje i dnes již zastaralé prvky.

3.3.

ASP.NET

ASP.NET17 je webový framework nabízený firmou Microsoft pro vytváření dynamických webových stránek, webových aplikací a webových služeb. Byl vydán roku 2002 jako nástupce technologie ASP. Díky podpoře CLR je aplikace možné psát ve všech jazycích kompatibilních s .NET Framework. Protože je nedílnou součástí .NET Frameworku, se kterým sdílí většinu vlastností, popíšeme si tyto vlastnosti nyní. Výhody • Zpětná kompatibilita - Framework poskytuje prostředky pro práci vně Frameworku jako jsou COM komponenty nebo nativní aplikace. • Všechny jazyky .NET jsou kompatibilní s Common Language Runtime (CLR) a mají garantované vlastnosti jako automatickou správu paměti, bezpečnost a ošetření vyjímek. • Nezávislost na jazyku - Protože .NET používá stejný Common Type System (CTS) pro všechny své jazyky, typy a instance objektů jsou mezi nimi přenositelné. • Bohatá knihovna Base Class Library (BCL) obsahuje pro všechny jazyky podporu čtení a zápisu souborů, grafického renderování, databází a manipulaci s XML. • .NET poskytuje bezpečnostní ochranu například pro přetečení bufferu. • Přenositelnost - Návrh .NET Frameworku je platformě nezávislý. Aplikace napsaná pro .NET Framework bude fungovat na všech platformách, pro které je .NET Framework implementován. Nevýhody 17

http://en.wikipedia.org/wiki/asp.net

19

• Aplikace s automatickou správou paměti běžně spotřebují více paměti než aplikace, které si řídí práci s pamětí přímo. • Zdrojový kód přeložený na MSIL bytekód je náchylnější k úspěšnému reverznímu inženýrství. • Novější verze .NET Frameworku nejsou předinstalované na operačních systémech a některé zabírají hodně místa na disku. • Jediná plná implementace .NET Frameworku existuje pro platformu Windows. Částečná implementace Mono vyvíjená firmou Novell existuje také pro platformy GNU/Linux, BSD, Unix, Mac OS X, Solaris a Windows. Stejně jako je možnost vybrat si z široké nabídky programovacích jazyků, i v rámci jednotlivých jazyků existuje mnoho způsobů realizace samotné webové aplikace. V následujícím textu si stručně popíšeme dostupné technologie pro tvorbu webových aplikací na platformě .NET a jejich zhodnocení18 . 3.3.1.

ASP.NET Web Forms

Cílem vývoje tohoto frameworku byla snaha odstranit klasické problémy bezstavového webového prostředí. Obsahuje množství ovládacích prvků, které usnadňují vývoj aplikací. Řeší problém oddělení aplikační vrstvy od prezentační a podporují výběr běhových kompilovaných jazyků. Je možné vytvářet znovu použitelné ovládací prvky[6]. Výhody • Zavedením stavového prostředí nad webem vytváří abstrakční vrstvu. Zavedením tohoto stavu z webu sice dělá něco co není, ale značně to usnadňuje tvorbu složitých, datově řízených aplikací. • Programátor zvyklý na vývoj klientského software může okamžitě začít programovat webové aplikace bez nutnosti znalosti webové architektury. Nevýhody • Aplikace napsané v tomto frameworku je značně obtížné automaticky testovat. • Nově vytvořený stav ve webovém prostředí je nutné si někde uchovávat. K tomu slouží skrytá proměnná ViewState. Tato proměnná i další typické automaticky generované části kódu se nepříznivě projevují v emitovaném kódu. Má to za následek špatnou optimalizaci pro vyhledávače, protože není možné plně kontrolovat výstupní HTML kód. 18

http://msdn.microsoft.com/en-us/magazine/dd942833.aspx

20

• Životní cyklus stránky a jejích prvků je velmi složitý. 3.3.2.

ASP.NET MVC Framework

ASP.NET MVC19 [8] je nový framework pro vytváření webových aplikací na platformě .NET. Obsahuje to nejlepší z MVC architektury, agilního vývoje a ASP.NET. Vznikl jako alternativa k WebForms, která poskytuje oddělení logických vrstev aplikace díky zavedení MVC návrhu architektury. MVC koncept není nový, poprvé byl použit v roce 1978 u jazyka SmallTalk. Jeho dnešní úspěch má na svědomí jazyk Ruby on Rails, který použití MVC při vyvíjení webových aplikací zpopularizoval. Uživatelská interakce s MVC aplikací odpovídá specifikaci REST. Uživatel zavolá akci kontroleru. Akce změní model a uživateli je vrácen zpět upravený pohled. Typická podoba URI MVC aplikace má tvar: /kontoler/akce/parametry Kontroler je třída obsahující metody jednoznačně odpovídající akcím. Pokud do prohlížeče zadáme například URI ve tvaru /Tests/Delete/0 bude zavolána metoda Delete kontroleru Tests a jako parametr jí bude předáno číslo 0. Výhody • Naprostá kontrola výstupního HTML. • Podpora Test driven development 20 a automatické generování neexistujícího kódu z kódu testovacích metod. • Oddělení logických vrstev aplikace. • Oddělení vrstev logiky samotných metod pomocí jejich atributů. Nevýhody • Absence mnoha ovládacích prvků, které jsou dostupné ve WebForms. Vytváření těchto prvků může být časově náročné. • Pochopení fungování celého frameworku, jakož i pochopení základní funkcionality Webu klade vysoké nároky na vzdělání programátora. 19 Model-View-Controller (MVC) je softwarová architektura, která rozděluje datový model aplikace, uživatelské rozhraní a řídící logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. 20 Metoda vývoje softwarových aplikací, který spoléhá na krátké vývojové cykly. Nejprve vývojář napíše testovací funkce a teprve potom napíše kód funkcí k testování tak, aby prošel testovacími funkcemi.

21

4.

Uživatelská příručka

Tato aplikace slouží studentům 1.ročníků. Po odeslání vyplněného testu bude uživateli doporučen předmět odpovídající jazykové úrovně. V následujícím textu představíme aplikaci a její funkcionalitu z pohledu různých uživatelských rolí.

4.1.

Struktura aplikace

Každá strana aplikace obsahuje následující ovládací prvky –odkaz na hlavní stranu, navigační menu a lištu aktuální pozice v rámci aplikace. Odkaz na hlavní stranu Hlavní menu Navigační lišta

Obrázek 1. Struktura aplikace.

4.2.

Nepřihlášený uživatel

Nepřihlásený uživatel má k dispozici základní pohled s dvěma vstupními stránkami –domovská stránka a stránka nápovědy k aplikaci. Může se přihlásit jako student nebo administrátor.

22

Přihlásit student

Přihlásit administrátor

Obrázek 2. Nepřihlášený uživatel.

4.3.

Přihlášený uživatel - student

Oproti nepřihlášenému uživateli obsahuje menu přihlášeného studenta jednu položku navíc –seznam testů. Příhlášený student Seznam dostupných testů

Obrázek 3. Menu - student.

4.3.1.

Seznam testů - student

Ze seznamu testů je možné spustit si vybraný test.

23

Seznam testů

Obrázek 4. Seznam testů - student.

4.3.2.

Zobrazení testu - student

Studentovi jsou zobrazeny detailní informace pro postup vyplňování a po zadání povinných položek a potvrzení dialogu je mu zobrazen samotný test.

Povinný dotazník

Obrázek 5. Informace o testu a povinný dotazník.

24

4.3.3.

Spuštění testu

Po vyplnění povinných položek formuláře je zobrazen samotný test. V pravém horním rohu je spuštěn odpočet času a na konci testu je zobrano tlačítko Odeslat pro odeslání testu. Zbývající čas pro vyplnění testu

Testové otázky

Tlačítko pro odeslání testu k vyhodnocení

Obrázek 6. Spuštěný test.

4.3.4.

Zobrazení výsledku testu - student

Po úspěšném vyplnění a odeslání testu bude uživateli zobrazen seznam jeho povinných a povinně volitelných předmětů společně s celkovým hodnocením a doporučením dalšího postupu při výběru vhodného předmětu ke studiu. Student má právo vyplnit každý test pouze jednou. Při každém dalším zobrazení testu mu již bude zobrazen pouze jeho předešlý výsledek. Pokud z nějakého důvodu potřebuje test opakovat, je to možno pouze s povolením administrátora.

25

Celkové bodové hodnocení

Slovní hodnocení

Seznam povinných, povinně volitelných nebo volitelných předmětů studenta

Obrázek 7. Celkové hodnocení, doporučení dalšího postupu a seznam předmětů studenta.

4.4.

Přihlášený uživatel - administrátor

Po úspěšném přihlášení získává administrátor přístup k následujícím položkám v menu –Testy, Statistika a Vizualizace. 4.4.1.

Seznam testů - administrátor

Pokročilý pohled na seznam testů. Administrátor má právo přidávat, editovat a mazat vytvořené testy. Pokud u některého testu existuje statistika výsledků vyhodnocení, vedle jména testu se zobrazí příslušný odkaz.

26

Přihlášený administrátor

Menu administrátora

Obrázek 8. Menu - administrátor.

Zobrazení testu

Úprava, smazání testu Statistiky testu Přidání nového testu

Obrázek 9. Seznam testů - administrátor.

4.4.2.

Zobrazení testu - administrátor

Při navigaci na konkrétní jazykový test ze seznamu testů se zobrazí souhrnné informace o vloženém testu. Stejně jako v seznamu testů je možné přejít odkazem Upravit do editačního formuláře testu. 4.4.3.

Editace testu

V editaci testu je možné vytvořit nový nebo editovat stávající test. Formulář editace testu obsahuje následující funkcionalitu: editace názvu, zadání, otázek, úrovní hodnocení a zpřístupnění testu. Pro uložení testu slouží tlačítko Uložit. Pro zrušení rozpracovaných změn slouží tlačítko Zrušit. 27

Úprava, mazání testu

Testové otázky

Informace o testu

Obrázek 10. Zobrazení testu - administrátor.

• Přidání otázky - Pro přidání otázky slouží odkaz Přidat otázku. Nová prázdná otázka bude přidána a zařazena jako poslední otázka. • Editace otázky - Při přidání nebo editaci stávající otázky je potřeba vyplnit její název, přidat odpovědi a zvolit správnou odpověd. • Smazání otázky - Pro smazání otázky v editačním formuláři slouží příslušné tlačítko Smazat otázku. • Pořadí otázek v testu - Pořadí otázek v testu je možné měnit přetažením dané otázky na jiné místo v testu. Po najetí kurzoru nad otázku se kurzor změní a indikuje tím možné uchopení a manipulaci s otázkou. • Přidání úrovně hodnocení - Pro přidání úrovní hodnocení slouží odkaz Přidat hodnocení. Nová prázdná úroveň hodnocení bude přidána a zařazena jako poslední úroveň hodnocení. • Editace úrovně hodnocení - Při přidání nebo editaci stávající úrovně hodnocení je potřeba vyplnit její bodové rozsahy a popis. Pokud student v testu získá počet bodů odpovídající dané úrovni hodnocení, bude mu zobrazen její popis. • Smazání úrovně hodnocení - Pro smazání úrovně hodnocení v editačním formuláři slouží příslušné tlačítko Smazat.

28

Povinný název testu

Editovat otázku

Přidat otázku

Přidat úroveň hodnocení

Editovat úroveň hodnocení Uložit, zrušit změny

Obrázek 11. Editace testu.

4.4.4.

Statistiky

Slouží pro správu výsledků vyhodnocení testů. Uložený výsledek každého vyhodnoceného testu je zobrazen v přehledné tabulce. Je možné určit počet výsledků v tabulce pomocí výběru počtu řádků z Počet řádků a třídit tabulku podle sloupců. Je možné označit některé výsledky přímo nebo všechny výsledky pomocí tlačítka Označit všechny. S označenými výsledky je možné dále pracovat pomocí tlačítek: Smaž označené a Export do CSV. Pokud je výsledků více než počet řádků v tabulce, dochází ke stránkování tabulky. • Smaž označené - Smaže všechny označené výsledky. • Export do CSV - Provede export označených položek do souboru a nabídne soubor ke stažení.

29

Označení pracovního výsledku

Počet řádků tabulky

Operace s označenými výsledky Zobrazení výsledku studenta

Obrázek 12. Statistika testů.

• Zobrazení výsledku - Každý uložený záznam je možné zpětně zobrazit pomocí odkazu Zobrazit. Takto vygenerovaný náhled výsledku je totožný s náhledem, který byl zobrazen studentovi při odeslání vyhodnoceného testu. Navíc obsahuje seznam otázek s označenou správnou nebo nesprávnou odpovědí studenta.

30

Celkové bodové hodnocení studenta

Informace o studentovi

Označená správná odpověd studenta

Obrázek 13. Zobrazení výsledku testu - administrátor.

4.4.5.

Vizualizace

Zobrazuje výsledky uložených vyhodnocení testu v přehledných grafech. Pro každý test jsou vygenerovány následující grafické statistiky: výsledky studentů podle úrovní hodnocení, studenti podle střední školy, studenti podle používané učebnice a studenti podle zkoušky. Vizualizace výsledků vyhodnocení testů se vztahuje pouze k uloženým výsledkům pro poslední verzi odpovídajícího testu.

31

Grafické statistiky výsledků testů

Obrázek 14. Vizualizace výsledků testů.

4.4.6.

Sitemap

Stromová struktura stránek obsahující odkazy pro snadnou navigaci na stránkách. Při přidání nového testu nebo smazání uloženého je navigace upravena automaticky. Pro triviálnost aplikace je navigace k dispozici pouze administrátorovi.

32

Navigační struktura stránek

Obrázek 15. Navigace v aplikaci.

5.

Programátorská příručka

Na základě závěrů uvedených v úvodních kapitolách byl jako hlavní programovací jazyk zvolen jazyk C# na platformě ASP.NET MVC Framework, jehož vývojové podmínky nabízí kombinaci výkonu v podobě kompilovaného kódu, efektivity moderního vývojového prostředí Visual Studio 2010 s integrovanou podporou vývoje všech fází projektu a MVC frameworku. Tato volba není jediná možná a důvody autora byly čistě věcí osobní preference.

5.1.

Požadavky na nasazení

Pro hostování aplikace je potřeba server IIS7. Na serveru musí být aktivováno zpracovávání souborů s koncovkou .less a nainstalována podpora MVC Frameworku. Samotná aplikace běží v Application Pool .NET Framework 4.0 a Pipeline mode Integrated. Složka App Data musí mít nastavena práva zápisu.

5.2.

Architektura aplikace

Architektura aplikace je postavená na ASP.NET MVC Frameworku. Jedná se o třívrstvou architekturu striktně oddělující jednotlivé vrstvy. Datovou vrstvu reprezentují modely (Model), aplikační vrstvu kontrolery (Controller) a prezenční vrstvu pohledy (View). Pokaždé když klient zašle požadavek na nějaký webový zdroj je tento požadavek nejprve přeposlán ke zpracování příslušnému kontroleru. Kontroler tento požadavek vyhodnotí, získá potřebná data z datového modelu a vrátí klientovi odpovídající pohled. 33

5.3.

Hlavní třídy

Použité třídy aplikace můžeme rozdělit podle toho, do které vrstvy aplikace patří. Mezi třídy datových modelů patří třídy popisující reálné objekty jako jsou jazykové testy, vyhodnocení testů, uživatelé a odpovědi na otázky. Tyto třídy neobsahují žádné řídící metody a slouží pouze jako datové kontejnery při přenosu dat z datových zdrojů. Třídy modelů v aplikaci se nacházejí ve složce /Models/ a jsou třídy: LanguageTest, Answer, ClassificationLevel, Question, Role, Statistic a AutoSave. Druhý typ tříd aplikace jsou třídy kontrolerů nacházející se ve složce /Controllers/. Každý kontroler zajišťuje část funkcionality aplikace. Nejdůležitější kontrolery v aplikaci jsou kontrolery pro správu testů (TestsController ), uživatelů (AccountController ), statistik výsledků (StatisticsController ) a navigace (SitemapController ). Kontrolery obsahují metody jejichž jména přímo odpovídají akcím, které mohou vykonávat (oprávnění) uživatelé aplikace. V dalším textu si uvedeme výčet konkrétních metod kontrolerů a budeme ho nazývat Programátorské API.

5.4.

Programátorské API

Programátorské API slouží k ovládání aplikace pomocí jednoduchého URI rozhraní, které odpovídá konkrétním metodám kontrolerů. Ke každému kontroleru existuje odpovídající pohled a model. Dále popíšeme nejdůležitější metody kontrolerů, ukázku jejich volání a návratové hodnoty. Pokud je návratovou hodnotou kontroleru ActionResult, znamená to, že bude vrácen odpovídající pohled. V případě, že je návratovou hodnotou JsonResult, bude vrácen blok HTML kódu jako odpověď na AJAX volání. 5.4.1.

Tests Controller

Slouží pro zobrazování a manipulaci s jazykovými testy. Většina jeho metod obsahuje kontrolu přístupových oprávnění pomocí atributu [Authorize(Roles=”Administrators”)]. • public ActionResult Index() - Načte data pro seznam testů. př. /Tests • public ActionResult View(int id) - Zobrazí test podle id. př. /Tests/1 • public ActionResult Create() - Zobrazí prázdný formulář pro vytvoření testu. 34

př. /Tests/Create • public JsonDelete(int id) - Zkusí smazat test podle id. př. /Tests/Delete/1 • public ActionResult Eval(int id) - Vyhodnotí test odeslaný uživatelem. př. /Tests/Eval/1 • public JsonResult Save(int id, string name, string description, string questions, string classification, bool enabled, string input) - Provede uložení nového nebo editovaného testu. • public JsonResult AddQuestion(int testId, int questionId) - Přidá novou otázku do editačního formuláře. • public JsonResult AddClassification(int id, int range) - Přidá novou úroveň hodnocení do editačního formuláře. 5.4.2.

Statistics Controller

Slouží pro práci se statistikami výsledků hodnocení. Většina jeho metod obsahuje kontrolu přístupových oprávnění pomocí atributu [Authorize(Roles=”Administrators”)]. • public ActionResult Index(int id=-1, int? page=0, int? rows=5, int? sort=9, int? asc=0) - Zobrazí tabulku výsledků vyhodnocení. Pokud není zavolán s parametry pro výpis tabulky, použije výchozí. př. /Statistics/1&page=1&rows=2&sort=3&asc=1 • public ActionResult Visualization() - Vytvoří a zobrazí grafické statistiky vyhodnocení testů. př. /Statistics/Visualization • public ActionResult Delete(int id) - Pokusí se smazat uloženou statistiku podle id. př. /Statistics/Delete/1 • public JsonResult AutoSave(int id, int[] answers, string email, string highSchool, string workBook, string exam) - Uloží rozpracovaný test studenta. • public ActionResult ExportToCsv(int id) - Provede export vybraných statistik testu podle id do souboru CSV. př. /Statistics/ExportToCsv/1 35

5.4.3.

Account Controller

Defaultní kontroler MVC Frameworku pro správu uživatelů a přihlašování k aplikaci. • public ActionResult LogOnUser(string userName, bool rememberme, string returnUrl) - Zkusí provést přihlášení uživatele. • public ActionResult LogOff() - Odhlásí přihlášeného uživatele. • public ActionResult Register(string userName, string email, string password, string confirmPassword) - Zkusí zaregistrovat nového uživatele. • public ActionResult ChangePassword(string currentPassword, string newPassword, string confirmPassword) - Zkusí změnit stávající heslo uživatele.

5.5.

Typické problémy a jejich řešení

Tato sekce popisuje implementaci pokročilých funkcí aplikace za pomoci použitých technologií. • Načítání dynamicky generovaných MVC ovládacích prvků za běhu aplikace - V editačním módu testu bylo pro každou otázku potřeba načítat netriviální bloky HTML kódu. Tento problém byl vyřešen kombinací AJAX a kódu vyhodnoceného na straně serveru. Po stisku odkazu Přidat otázku dojde k odeslání požadavku na server, kde je vyhodnocen kód znovupoužitelného ovládacího prvku, a ten je vzápětí vrácen jako HTML návratovou hodnotou. • SOAP dotazování nad webovými metodami Stagu - Pro ověřování a získání informací o studentovi jsou použity webové metody stagu21 . Stejně tak při vyhodnocení testu jsou studentovi doporučeny jeho povinné a povinně volitelné předměty ze stagu. Pro komunikaci ze stagem používá naše aplikace proxy třídu automaticky vygenerovanou a následně zkompilovanou do podoby dll knihovny z WSDL22 souboru. • Metadata pro navigaci na stránkách - Metadata ve webové aplikaci popisují navigační strukturu webových stránek v rámci jednoho doménového jména. Obecně existují dva způsoby zjištění organizace stránek, buď analýzou všech odkazů vedoucích z hlavní stránky a rekurzivním následováním všech odkazů ze všech takto nalezených stránek se stejným doménovým prefixem nebo poskytnutí sitemap souboru. Naše aplikace generuje potřebná metadata automaticky podle aktuálního obsahu webových stránek a používá je pro vizualizaci navigační struktury stránek. 21 22

http://stagservices.upol.cz/ws/help/ Web service definition language

36

• Atributy metod kontrolerů - Atributy metod kontrolerů slouží pro zavolání určitého kódu před (během nebo po) voláním samotné metody kontroleru. Tím, že odstiňují samotné tělo metody od zbytečného kódu, zpřehledňují syntaxi jazyka. Naše aplikace používá atributy pro kontrolu oprávnění volání metod, zachytávání chybových hlášení a následné přesměrování a rozlišování jednotlivých submit tlačítek v rámci formuláře a přesměrování na odpovídající metody kontroleru.

5.6.

Klientské technologie

Pro realizaci asynchroních javascriptových volání a manipulaci s DOM stromem byla použita knihovna jQuery, kterou lze libovolně nahradit kteroukoli z volně dostupných alternativ. Mezi její hlavní výhody patří vlastnosti jako (malá) velikost, ovládání, kompatibilita, rozšířenost a rozšiřitelnost. Paradoxně v našem projektu nepoužíváme pro AJAX datový formát XML, i když písmeno x ve slově AJAX znamená XML. Protože chceme přenášená data udržet v co nejmenší velikosti, používáme pro komunikaci JSON. Tímto nám také odpadá potřeba parsovat XML na klientské stanici[4]. Bezpečnost pro přístup k volání funkcí AJAX řeší pravidlo Same origin policy 23 , které povoluje pouze běh skriptu nacházejícího se na stránce jeho původu a nelze tedy volat skripty z jiné domény. Tím je zabezpečeno, že citlivá data o výsledcích dotazu nebudou zneužita podvržením fiktivního dotazu na AJAX metody kontroleru. Navíc MVC framework implicitně zakazuje posílání HTML kódu přes editační formuláře.

5.7.

Volba datového modelu

Aplikace byla navržena obecně tak, aby mohla používat libovolný datový zdroj. Týká se to správy uživatelů, rolí, ukládání testů a výsledků testů a autosave funkcionality. Pro ukládání těchto dat existuje rozhraní, které každý poskytovatel dat musí implementovat. Pro změnu poskytovatele dat pak stačí pouze v souboru nastavení aplikace přidat sekci nastavení daného poskytovatele, aktivovat ho u konkrétní funkcionality a aplikace začne automaticky využívat jeho služeb. Pro jednoduchost ve výchozím nastavení aplikace používá pro ukládání všech svých dat XML datové poskytovatele.

5.8.

Grafické zpracování

Aplikaci byl dán unifikovaný vzhled jednotný s dalšími aplikacemi Univerzity Palackého, tak aby uživatelé byli co možná nejméně vystaveni stresu při práci s 23

http://en.wikipedia.org/wiki/same origin policy

37

novou aplikací. Pro definici CSS stylů byla použita knihovna .LESS 24 , která řeší problémy statických kaskádových stylů: • Nemožnost definovat proměnné. Například: @color: #4D926F; #header { color: @color; } • Dědit styly z jiných tříd a používat funkce. Například: .box (@param: 5px) { border: @param; } #header { .box(2px); } • Stromové definice. Například: #header { color: red; a { text-decoration: none; } } Navíc tato knihovna umí komprimovat styly a šetří tak čas při jejich načítání.

5.9.

Metodologie vývoje

S přihlédnutím ke znalosti klienta, jeho dobré časové dostupnosti, známého postupu pro vyhodnocování testů, nejasné představy o převedení testů do elektronické podoby a následné časté potřebě změn byla jako hlavní metodologie vývoje zvolena metodologie Iterativní vývoj. Práce byla rozdělena na úlohy délky pět dní / člověk a v každém cyklu provedena fáze analytická, návrh, implementace a testování. Každý týden proběhla pracovní schůzka s vedoucím a představitelem zákazníka, na které byla představena a nabídnuta k otestování nová funkcionalita. 24

http:/lesscss.org

38

5.10.

Správa verzí a řízení projektu

Pro správu verzí, systém řízení úkolů a hlášení chyb byl provozovám Team Foundation Server 2010. Jeho integrace do vývojového prostředí pomohla jak konzistenci projektu, kdy vedoucí měl možnost logování chyb a kontroly jejich opravení, tak i zvýšení bezpečnosti uchovávání zdrojových kódů jejich archivováním na repozitářovému serveru.

5.11.

Logování chyb

Pro logování chyb na straně serveru byla použita volně dostupná aplikace Elmah25 . Každá nezachycená chyba je nejprve zachycena handlerem Elmah, zalogována a poté znovu vyvolána. Uložený záznam je poté možné kdykoliv zobrazit ve stejné podobě v jaké byla původní chyba vyvolána.

5.12.

Ladění

Správné použití asynchroních volání přináší uživateli zážitek ne nepodobný tomu, na co je zvyklí z desktopových aplikací. Na druhou stranu však také přináší velké nároky na programátora. Skutečnost, že prosazení této dlouhou dobu známé technologie trvalo tak dlouho, je výsledkem nesnadného osvojení si dané techniky. Pro důkladné porozumění běhu aplikace jsou nezbytné ladící nástroje typu HTTP Proxy. Takové nástroje umožnují sledovat real-time komunikaci mezi webovou aplikací a serverem, včetně jednotlivých hlaviček requestů. Pro tuto činnost byl použit doplňek Firebug26 prohlížeče Firefox. Ten zatím jako jediný umožnuje sledovat aktuální stav DOM i po dynamicky provedených změnách.

25 26

http://code.google.com/p/elmah/ http://getfirebug.com/

39

Závěr Vývoj aplikace netrpěl žádným z typických problémů vývoje softwaru jako jsou nedodržení ceny, termínu nebo kvality. Aplikace byla napsána použitím nejmodernějších technologií na minimálním počtu řádků zdrojového kódu. To se projevilo v dobré udržovatelnosti a škálovatelnosti, v malém počtu chyb a konzistentním programátorském API. Aplikace vyřešila problém klienta a je přínosem potenciálních uživatelů.

40

Conclusions A development of the application didn’t suffer any typical problems involving software development domain such as cost, time and quality. Application was written using the latest technologies in minimum lines of code which proved in good maintainability and scaleability, low number of errors and consistent API. Application thus resolved client’s problem and is beneficial for it’s potentional users.

41

Reference [1] Y. Deshpande, S. Murugesan, A. Ginige, S. Hansen, D. Schwabe, M. Gaedke, and B. White Web Engineering, Journal of Web Engineering, Vol. 1, No.1, pp 003-017, New Jersey, 2002. [2] M. Gaedke, M. Grossniklaus, and O. D ’(Eds.) ICWE 2009, LNCS 5648, pp. 300-314, Springer, 2009. [3] G. Kappel, B. Pröll, S. Reich, W. Retschintzegger Web Engineering - The Discipline of Systematic Development of Web Applications John Wiley & Sons Inc., Heidelberg, 2003 [4] King, Andrew B. Website Optimalization. O’Reilly Media, Inc., Sebastopol, 2008. [5] AL Zabir, Omar Building a Web 2.0 Portal with ASP.NET 3.5. O’Reilly Media, Inc., Sebastopol, 2007. [6] Liberty, Jesse Programming C# 2.0 O’Reilly Media, Inc., Sebastopol, 2002. [7] Jalote, Pankaj A Concise Introduction to Software Engineering Springer, London, 2008. [8] Esposito, Dino Programming Microsoft ASP.NET MVC Microsoft Press, Redmond, 2010 [9] Esposito, Dino Programming Microsoft ASP.NET 2.0 Core Reference Microsoft Press, Redmond, 2006. [10] Naumann, Friedrich Dějiny informatiky : od abaku k internetu Academia, Praha, 2009. [11] Cerf, Vint Future of Global Web Technology, Soul, 2008, záznam http://kr.youtube.com/watch?v=hf0rjtnwc9a

42