Elektronická podpora výuky předmětu Komprese dat

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Elektronická podpora výuky předmětu Komprese dat Vojtěch Ouška

Vedoucí práce: Ing. Miroslav Balík, Ph.D.

Studijní program: Informatika a výpočetní technika květen 2006

Volný list iii

iv

Poděkování Rád bych poděkoval všem lidem, kteří mi byli nápomocni při sestavování a vytváření této diplomové práce. Zde bych rád vyzdvihl pana Ing. Miroslava Balíka, Ph.D. za jeho vedení a věcné připomínky. Dále pak mé ženě, Bc. Janě Ouškové, Dis., za pomoc při korektuře a za trpělivost při probděných nocích. Velký dík patří také celé mé rodině za podporu v dobách studia.

v

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 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ů (autorský zákon).

V Praze dne 20.5. 2006

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

vii

Abstract The main aim of this work is to design and implement software system for students testing via dynamically generated tests concerning the data compression problems. The system tries to help lectors to provide e-learning form of studying. However it provides a possibility for student self-testing using trial test as well.

Abstrakt Cílem této diplomové práce je navrhnout a realizovat systém pro automatické testování studentů pomocí dynamicky generovaných testů zabývajících se problematikou komprese dat. Systém slouží jako pomůcka pro hodnocení studentů e-learningovou formou, ale zároveň i jako vhodný materiál pro samotné studenty, kteří si pomocí zkušebních testů mohou ověřovat hloubku svých znalostí problematiky komprese dat.

ix

Obsah Seznam obrázků

xv

1 Úvod

1

2 Cíl práce

5

3 Definice a specifikace požadavků

7

3.1

Definice pojmů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2

Uživatelské role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.1

Administrátor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.2

Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.3

Neregistrovaný uživatel . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.3

Typy otázkových šablon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.4

Druhy testů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5

Hodnocení studentů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.6

Jazykové mutace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.7

Bezpečnost systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.8

Správa systémových zdrojů . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4 Tvorba analytického modelu 4.1

15

Relační model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.1.1

Závislost mezi otázkou a její šablonou . . . . . . . . . . . . . . . . . . .

18

4.1.2

Jazykové mutace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.2

Funkční model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.3

Životní cyklus testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5 Návrh systému 5.1 5.2

25

Modul pro prezentaci kompresních algoritmů . . . . . . . . . . . . . . . . . . .

25

5.1.1

Struktura modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

Modul pro testování studentů . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

5.2.1

Typ aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

5.2.2

Návrh struktury aplikace . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6 Realizace 6.1

31

Modul pro prezentaci kompresních algoritmů . . . . . . . . . . . . . . . . . . .

31

6.1.1

Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

6.1.2

Grafický vzhled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

xi

6.1.3 6.2

Podepisování JAR archivů . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Modul pro testování studentů . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

6.2.1

Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

6.2.1.1

Aplikační server . . . . . . . . . . . . . . . . . . . . . . . . . .

32

6.2.1.2

Databázový server . . . . . . . . . . . . . . . . . . . . . . . . .

33

6.2.1.3

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

34

6.2.1.4

Rámce pro vývoj aplikace . . . . . . . . . . . . . . . . . . . . .

35

6.2.2

Struktura tříd systému . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

6.2.3

Zabezpečení systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

6.2.3.1

Autentizace a autorizace . . . . . . . . . . . . . . . . . . . . .

38

6.2.3.2

Prolomení autorizace . . . . . . . . . . . . . . . . . . . . . . .

38

6.2.3.3

Vkládání XHTML entit do uživatelského vstupu . . . . . . . .

40

6.2.3.4

Vkládání SQL příkazů do uživatelského vstupu . . . . . . . . .

40

Implementace grafického rozhraní testových otázek . . . . . . . . . . . .

41

6.2.4.1

Testová otázka typu AnswerOne . . . . . . . . . . . . . . . . .

42

6.2.4.2

Testová otázka typu AnswerMany . . . . . . . . . . . . . . . . .

42

6.2.4.3

Testová otázka typu AnswerText . . . . . . . . . . . . . . . . .

43

6.2.5

Dynamické otázky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

6.2.6

Správa obrázků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2.6.1

Statické obrázky . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2.6.2

Dynamické obrázky . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2.7

Tisk testů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

6.2.8

Správa uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.8.1

Postupné vkládání . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.8.2

Hromadný import . . . . . . . . . . . . . . . . . . . . . . . . .

49

Databázový pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.10 Doba trvání testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.2.11 Generování pouze jednoho ostrého testu . . . . . . . . . . . . . . . . . .

54

6.2.12 Podpora vícejazyčných verzí . . . . . . . . . . . . . . . . . . . . . . . . .

55

6.2.13 Logování událostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.2.14 Akceptační testy aplikace . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.2.4

6.2.9

7 Rozhraní pro vytváření dynamických otázek 7.1

Popis rozhraní

59

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

60

7.1.1

Rozhraní DynamicQuestion . . . . . . . . . . . . . . . . . . . . . . . . .

60

7.1.2

Rozhraní DynamicQuestionText . . . . . . . . . . . . . . . . . . . . . .

61

7.1.3

Rozhraní DynamicQuestionOption . . . . . . . . . . . . . . . . . . . . .

61

xii

7.1.4

Rozhraní DynamicQuestionOne . . . . . . . . . . . . . . . . . . . . . . .

62

7.1.5

Rozhraní DynamicQuestionMany . . . . . . . . . . . . . . . . . . . . . .

62

7.2

Pořadí volaných metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

7.3

Serializace objektů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.4

Generování dynamického obrázku . . . . . . . . . . . . . . . . . . . . . . . . . .

64

7.5

Příklady implementace zásuvných modulů . . . . . . . . . . . . . . . . . . . . .

64

7.5.1

Příklad 1 - Hledání podřetězců . . . . . . . . . . . . . . . . . . . . . . .

64

7.5.2

Příklad 2 - Huffmanovo kódování

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

67

Testování zásuvných modulů . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

7.6.1

74

7.6

Popis aplikace Plugin Tester . . . . . . . . . . . . . . . . . . . . . . . . .

8 Závěr

77

9 Literatura

79

A Seznam použitých zkratek

81

B Instalační příručka

83

B.1 Instalace PostgreSQL

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

83

B.1.1 Operační systém Windows XP . . . . . . . . . . . . . . . . . . . . . . .

83

B.1.2 Operační systém Linux . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

B.2 Instalace aplikačního serveru Apache Tomcat . . . . . . . . . . . . . . . . . . .

85

B.2.1 Operační systém Windows XP . . . . . . . . . . . . . . . . . . . . . . .

85

B.2.2 Operační systém Linux . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

B.2.3 Potřebná rozšíření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

B.3 Instalace systému SyVyKoD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

B.3.1 META-INF/context.xml . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

B.3.2 WEB-INF/web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

C Administrátorský manuál

93

C.1 Přihlášení do systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

C.2 Vytváření skupin uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

C.3 Vytváření uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

C.4 Vytváření kategorií . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

C.5 Vytváření otázkových šablon . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

C.6 Vytváření šablon testů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

C.7 Přidávání zásuvných modulů . . . . . . . . . . . . . . . . . . . . . . . . . . . .

98

C.8 Průběh testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

C.9 Údržba aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

xiii

C.9.1 Základní funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

C.9.2 Logování událostí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

100

C.9.3 Správa obrázků . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

100

D Obsah přiloženého CD

101

D.1 Obsah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

D.2 Text diplomové práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

D.3 Systém Syvykod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

D.4 Potřebný software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101

xiv

Seznam obrázků 3.1

Schéma pro vytváření testových šablon . . . . . . . . . . . . . . . . . . . . . . .

11

4.1

E-R model systému SyVyKoD . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.2

Model případu použití (Use Case diagram) systému SyVyKoD . . . . . . . . .

20

4.3

Diagram datových toků - Neregistrovaný uživatel . . . . . . . . . . . . . . . . .

21

4.4

Diagram datových toků - Student . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.5

Diagram datových toků - Administrátor . . . . . . . . . . . . . . . . . . . . . .

22

4.6

Dynamický model životního cyklu testu . . . . . . . . . . . . . . . . . . . . . .

24

5.1

Použití návrhového vzoru MVC v základní struktuře aplikace . . . . . . . . . .

28

6.1

Ukázka grafického rozhraní otázky typu AnswerOne . . . . . . . . . . . . . . . .

42

6.2

Ukázka grafického rozhraní otázky typu AnswerMany . . . . . . . . . . . . . . .

43

6.3

Ukázka grafického rozhraní otázky typu AnswerText . . . . . . . . . . . . . . .

44

6.4

Zobrazování dynamických obrázků . . . . . . . . . . . . . . . . . . . . . . . . .

47

7.1

Struktura rozhraní pro dynamické otázky . . . . . . . . . . . . . . . . . . . . .

59

7.2

Pořadí volání metod zásuvných modulů . . . . . . . . . . . . . . . . . . . . . .

63

7.3

Generovaný obrázek k příkladu Huffmanovo kódování . . . . . . . . . . . . . .

67

7.4

Aplikace Plugin Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

xv

Kapitola 1 Úvod Mezi známá didaktická pravidla patří tvrzení, které přisuzuje důkladnému ověřování pochopení učiva stejnou váhu jako jeho výkladu. V dnešní době, kdy se oblibě začínají těšit různé formy „dálkovéhoÿ studia, vzniká celá řada systémů pro podporu e-learningových kurzů. E-Learning je poměrně nový, velice široký pojem, pod kterým si lze představit celou řadu věcí týkajících se problematiky výuky podporované informačními technologiemi. Za nejzákladnější formu e-learningu lze považovat převádění existujících studijních materiálů do elektronické podoby - tzv. e-dokumentů. Další stupeň zahrnuje různé formy testování a metody komunikace mezi studenty pomocí audiovizuálních prostředků. Nejpokročilejší formy e-learningu nabízejí dokonce počítačové simulace laboratorních pokusů atd. Proces zavádění e-learningu je poměrně zdlouhavý. Důkazem je zatím nízké zastoupení vzdělávacích institucí, které by na tuto formu studia byly plně odkázány. Ovšem existují výjimky, které na e-learningu úspěšně postavili převážnou část výuky. Příkladem může být společnost Cisco a její vzdělávací program Cisco Networking Academy (CNA). Pro podporu e-learningového způsobu výuky existuje celá řada profesionálních produktů nazývaných course management systems (CMS) nebo také learning management systems (LMS). Ty mají velice propracovanou výukovou část. Většina z nich obsahuje propracovanou podporu komunikace uživatelů, podporu diskusních skupin, nástěnek, sdílení aplikací, video konferencí, virtuálních tříd atd. Vedle komerčních produktů (WebCT, Authorware, produkty firmy Macromedia atd.) existují i open-source systémy, které narozdíl od předchozích nevyžadují znalosti speciálních softwarových technologií. Mezi asi nejrychleji se rozšiřující patří produkt Moodle (Modular Object-Oriented Dynamic Learning Environment). Jedná se o modulové objektově orientované dynamické vzdělávací prostředí určené pro podporu prezenční i distanční výuky prostřednictvím online kurzů dostupných na WWW. Nevýhoda všech zmíněných systémů spočívá v poměrně obtížném nasazování do procesu výuky. Kvůli jejich flexibilitě nastavení a širokým možnostem může být těžké se v takovýchto e-learningových systémech rychle zorientovat. Cílem této práce je vytvoření systému, který tento problém odstraňuje. Zároveň více než na prezentování učiva se zaměřuje na testování studentů. Tímto se nejvíce odlišuje od existujících produktů. Jeho přehledné webové rozhraní umožňuje rychlé a snadné vytváření testovacích materiálů. Vedle snadné instalace se také vyznačuje možností vytváření dynamických otázek, které jsou generovány pomocí Java tříd snadno integrovatelných do systému. Automatické testování osvojených znalostí (u e-learningových kurzů preferované) musí zaručit podobné podmínky, kterým jsou studenti vystaveni u zkoušení klasického, v nejčastěj-

1

2

KAPITOLA 1. ÚVOD

ším případě zkoušení písemným testem či ústní formou. Toho se dá celkem snadno dosáhnout v případě, kdy jsou studentům předkládány testy připravené přímo lektorem. Ovšem v situacích, kdy systém vytváří jednotlivé testy dynamicky, musí být kladen velký důraz na to, aby testy byly srozumitelné, jednotlivé otázky podobně složité a v neposlední řadě, aby vyhodnocené testy tvořily přehledný podkladový materiál pro ohodnocení studenta. Navržení systému, který má splňovat výše uvedené podmínky a přitom nabízí lektorům příjemný způsob, jak flexibilně, rychle a hlavně snadno připravovat testovací materiály, není vůbec triviální. Cílem této diplomové práce je navržení a implementování právě takovéhoto systému. Práce je rozčleněna do následujících kapitol:

Kapitola 1 představuje obecný úvod do problematiky e-learningových kurzů.

Kapitola 2 specifikuje cíle, kterých by tato diplomová práce měla dosáhnout a popisuje v jakém směru navazuje na práce předchozí.

Kapitola 3 seznamuje se specifikací systému. Zároveň zavádí pojmy, které pomáhají popisovat jeho jednotlivé části. V této kapitole se z původních slovních požadavků vyčleňují podstatná fakta a hlavní komponenty systému. Obsah kapitoly určuje jakým směrem se bude vývoj projektu ubírat. Mimo jiné rozděluje uživatelské role a druhy podporovaných otázek.

Kapitola 4 popisuje analytickou část projektu. Pomocí modelů představuje jednotlivé komponenty systému a jejich vzájemnou interakci. V kapitole jsou uvedeny různé možnosti návrhů vztahů těchto komponent. U jednotlivých možností jsou zmíněné výhody a nevýhody toho či onoho přístupu. Diagramy dynamického modelu pomáhají pochopit funkce, které systém nabízí a zároveň definuje ty uživatele, kteří jsou oprávněni nabízené funkce provádět. V závěru kapitoly je popsán životní cyklus testu, jehož pochopení je pro další orientaci v textu nezbytně nutné.

Kapitola 5 popisuje návrh systému. Ve svém popisu opouští abstraktní úroveň vývoje a začíná pracovat s konkrétními technologiemi. Ještě se však nepouští do vysvětlování technických detailů implementace. Představuje střední vrstvu popisu struktury aplikace. Čtenář by měl po přečtení nabýt dojmu o tom, jak systém funguje. Popis je prováděn pomocí návrhových vzorů a blokových schémat.

Kapitola 6 je popisem samotné realizace. Objevuje se zde popis problémů, které v rámci vývoje nastaly, a jejich konkrétní řešení. Pro větší přiblížení problematiky obsahuje kapitola příklady a klíčové úseky kódu, které řeší nastíněné problémy. Konkrétně se kapitola zabývá bezpečností systému, správou uživatelů, zaručením regulérních podmínek při ověřování znalostí studentů, správou demonstračních obrázků atd.

KAPITOLA 1. ÚVOD

3

Kapitola 7 je velice důležitá pro tvůrce rozšíření testovacích materiálů. Obsahuje detailní popis návrhu Java tříd (tzv. zásuvných modulů otázek) reprezentujících dynamické otázky. Popis programových rozhraní je doplněn kódem ukázkových modulů. Konec kapitoly představuje nástroj pro ověřování správnosti návrhu takovýchto modulů. Kapitola 8 shrnuje výsledky a uzavírá tuto práci. Přílohy obsahují především materiály nutné k instalaci potřebných softwarových komponent a systému samotného. Administrátorský manuál obsahuje informace vhodné pro snazší orientaci v systému, popisuje základní administrátorské akce a upozorňuje na věci, kterým je třeba při správě systému věnovat zvýšenou pozornost.

Kapitola 2 Cíl práce Cílem této práce je navržení a implementace systému pro podporu výuky předmětu Komprese dat, vyučovaném na Fakultě elektrotechnické Českého vysokého učení technického. Realizace systému si klade za cíl nabídnout dva moduly: • modul prezentující informace o vyučovaných algoritmech, • modul pro automatické a dynamické testování studentů. První modul navazuje na předchozí diplomové práce vytvářené pro Stringologickou skupinu Elektrotechnické fakulty, zejména pak na práci Ondřeje Hanouska [1] a na semestrální práce studentů předmětu 36KOD. Tyto práce se zabývají tvorbou vizualizačních Java appletů. Modul nabízí rozhraní pro tyto applety a prezentuje je formou webových stránek. Cílem druhé části je vytvoření vícejazyčné webové aplikace, nabízející možnost snadného vytváření testových materiálů, ze kterých je možné generovat testy. Ačkoli je aplikace vytvářena pro potřeby vyučujících předmětu 36KOD, její obecný návrh umožňuje nasazení ve všech oblastech, kde je zapotřebí ověřovat znalosti studentů pomocí e-learningových testů.

5

Kapitola 3 Definice a specifikace požadavků Systém pro podporu výuky se odlišuje od běžných webových aplikací několika vlastnostmi. Navrhovaný systém umožňuje generování testů dynamicky pomocí algoritmů integrovaných do systému. Systém se zaměřuje na řešení těchto problémů: • realizace rozhraní pro snadné vytváření testových šablon a otázek, • možnost vytváření dynamických otázek pomocí algoritmů řešících libovolný výpočetní problém (tzv. zásuvných modulů1 otázek), • ošetření regulérního průběhu vyplňování testu, • striktní zabezpečení proti neoprávněným změnám dat a neoprávněným akcím, • variabilní metody hodnocení studentů. Výše zmíněné problémy budou podrobně rozebrány dále v textu. Nejprve však následuje seznam zavedených pojmů.

3.1

Definice pojmů

Systém SyVyKoD Pojem systém SyVyKoD je používán jako zkrácené označení názvu Systém pro podporu výuky předmětu Komprese dat. Pokud nehrozí záměna pojmů, je používán pouze termín systém. Testová otázka Testová otázka (zkráceně otázka) reprezentuje konkrétní podobu příkladu, který mají studenti za úkol vyřešit. Šablona otázky Pojem šablona otázky (nebo také otázková šablona) představuje objekt, který souhrnně popisuje vlastnosti generovaných otázek jednoho typu. Jedná se především o částečné znění zadání, čas stanovený na vypracování otázky, počet bodů za správnou a špatnou odpověď atd. V případech, kdy nehrozí záměna pojmů, je používán pouze termín šablona. Nejsnáze si lze šablonu představit jako záznam popisující vzor, podle kterého se konkrétní testové otázky generují. Tento záznam může obsahovat například tyto informace: „Určete součet čísel a a b. Za správnou odpověď obdržíte 10 bodů, za špatnou 0 bodů.ÿ Pro otázku generovanou z této šablony systém náhodně 1

Termín zásuvný modul je používaný jako český ekvivalent k anglickému termínu plugin.

7

8

KAPITOLA 3. DEFINICE A SPECIFIKACE POŽADAVKŮ

zvolí konstanty a a b a dosadí je do sčítanců v textu. Tím vzniká konkrétní otázka, u které už je možné kontrolovat správnost odpovědi.

Test Termínem test je označována množina testových otázek. Na vypracování každého testu existuje časový limit, po jehož překročení není dále možné na otázky odpovídat.

Kategorie Pojmem kategorie je označována množina otázkových šablon zabývajících se podobnou problematikou.

Šablona testu Ze šablon testů (v případě, že nehrozí záměna s pojmem šablona otázky, je používán termín šablona) jsou generovány konkrétní testy. Šablony testů obsahují informace o tom, které kategorie se při vytváření testu použijí.

Skupina Termínem skupina je označována množina sdružující studenty společných vlastností.

Zásuvný modul otázky Pojmem zásuvný modul otázky (zkrácené modul ) se označuje Java program, který umožňuje generovat znění otázek. Moduly lze do systému jednoduše přidávat a přiřazovat je jednotlivým otázkovým šablonám. Právě modul by byl ve výše uvedeném příkladu zodpovědný za generování hodnot čísel a a b.

Jazyková mutace Pod pojmem jazyková mutace se obecně myslí texty přeložené do cizího jazyka. Konkrétně se pak jedná o jazykové mutace aplikace, šablon otázek, šablon testů a zásuvných modulů.

Dynamický obrázek Dynamický obrázek je zde chápán jako obrázek vygenerovaný programově zásuvným modulem na základě zvolených hodnot parametrů. Neznamená to, že by se obrázek v průběhu času měnil.

Statický obrázek Tento pojem představuje obyčejný obrázek uložený v souboru souborového systému. Jeho obsah je v rámci systému neměnný.


3.2

9

Uživatelské role

Systém umožňuje prezentaci podpůrných materiálů k výuce předmětu Komprese dat a po autorizovaném vstupu testování znalostí studentů. Systém je založen na modelu klient-server. Spojení klientské části se serverovou je zajištěno pomocí webového prohlížeče, přes který uživatelé žádají o informace. Ty jsou aplikačním serverem zasílány zpět klientské straně. Aplikační server úzce spolupracuje s databázovým serverem, kde jsou uložena data využívaná systémem. Po přihlášení uživatele do systému se jeho vlastnosti liší podle následujících uživatelských rolí. 3.2.1

Uživatelská role Administrátor

Administrátor má privilegia ke spravování systému, nastavování vlastností a pozorování probíhajících událostí. Předpokládá se, že administrátor má zároveň oprávnění ke konfiguraci aplikačního a databázového serveru. Základním úkolem administrátora je sestavování šablon testů a otázek, ze kterých si uživatelé generují konkrétní testy. Typickou osobou, která v systému vystupuje v roli administrátora, je vyučující předmětu. Kromě přípravy testů má administrátor za úkol také správu studentů. Ty může přidávat do systému postupně nebo může využít funkci hromadného importu uživatelů. Poslední funkcí administrátora je dohlížení na bezproblémový chod systému. K tomu může použít nástroj pro logování událostí, který zaznamenává veškeré události, které se v systému odehrály. 3.2.2

Uživatelská role Student

Pod touto rolí vystupují v systému uživatelé, kteří mají možnost se do systému přihlašovat a pomocí něho skládat testy. Student může také upravovat své osobní údaje, které slouží administrátorovi v případě nutnosti kontaktování studenta. Kvůli zvyklostem v názvosloví je někdy role student označována jako role Uživatel. V případech, kdy se například mluví o údajích studentů, je běžnější používat pojem uživatelské heslo než heslo studenta. V žádném případě však nesmí docházet k záměně role Student s rolí Neregistrovaný uživatel. 3.2.3

Uživatelská role Neregistrovaný uživatel

Za neregistrovaného uživatele se považuje každý návštěvník systému, který nemá oprávnění k přihlášení. První modul systému, zabývající se prezentací vizualizačních appletů, je plně k dispozici i neregistrovaným uživatelům.

3.3

Typy otázkových šablon

Otázkové šablony mohou mít různé vlastnosti. Kombinací těchto vlastností vznikají různé typy šablon. Systém podporuje celkem 5 takových typů. Při vytváření nové šablony musí adminis-

10


trátor šabloně jeden z těchto typů přiřadit. Následující text uvádí seznam vlastností, kterými se může šablona vyznačovat.

Static Šablony s touto vlastností vytvářejí otázky, které mají vždy stejné zadání. Toto zadání je v plném znění uvedeno přímo v šabloně.

Dynamic Šablonám s vlastností Dynamic je přiřazen zásuvný modul, který při vytváření otázky ovlivňuje její zadání. Může například náhodně generovat sčítance v otázce zaměřené na znalost operace sčítání.

AnswerMany Šablony s vlastností AnswerMany generují otázky, u kterých student vybírá z nabízených možností ty, které považuje za správné. U typu AnswerMany se počet správných odpovědí pohybuje v rozmezí 0. .n, kde n je celkový počet odpovědí.

AnswerOne Šablony s vlastností AnswerOne se oproti AnswerMany liší pouze v tom, že generují právě jednu správnou odpověď.

Option Vlastnost Option představuje souhrnné označení šablon s vlastností AnswerOne a AnswerMany.

AnswerText Na otázky generované tímto typem šablon odpovídá student pomocí textového řetězce vloženého do vstupního textového pole. Ten je porovnáván se správnou odpovědí. Příkladem může být otázka, kdy student musí zadat výstupní řetězec procesu kódování ze znalosti vstupního řetězce.

ImageGenerator Šablony s vlastností ImageGenerator generující dynamický obrázek.

Na základě kombinací uvedených vlastností systém rozlišuje 5 konkrétních typů šablon. Tabulka 3.1 v levém sloupci uvádí seznam těchto typů a v pravých sloupcích definuje, jaké vlastnosti tyto šablony mají. Jestliže se šablona některou z vlastností vyznačuje, pak je u této vlastnosti uveden symbol +. Tři poslední šablony mohou mít také vlastnost ImageGenerator, v závislosti na tom, zda generují či negenerují dynamický obrázek.

KAPITOLA 3. DEFINICE A SPECIFIKACE POŽADAVKŮ Typ šablony StaticOne StaticMany DynamicOne DynamicMany DynamicText

Static + +

Dynamic

+ + +

Vlastnosti šablon AnswerOne AnswerMany + + + +

11

AnswerText

Option + + + +

+

Tabulka 3.1: Přehled podporovaných typů šablon otázek a jejich vlastností

Každá šablona otázky spadá do právě jedné kategorie. Výhoda zavedení kategorií spočívá v přehledném uspořádání šablon do logických celků. Administrátor má možnost tyto kategorie vytvářet a upravovat. Skládáním kategorií dohromady pak vytváří šablony testů. K šablonám přiřazuje jednotlivé kategorie a zároveň určuje, kolik otázek se z jednotlivých kategorií použije při vytváření testu. Šablony testů mají příznak nastaveny buď na aktivní nebo neaktivní. Studenti pak v závislosti na tomto příznaku mohou nebo nemohou testy generovat. Celý proces sestavování šablon je vidět na obrázku 3.1, kde jsou vytvořené 2 šablony testů, z nichž je možné generovat testy. Šablona Testu 1 generuje 2 otázky z Kategorie A a 1 otázku z Kategorie B. Šablona testu 2 generuje test se 3 otázkami pouze z Kategorie B.

Obrázek 3.1: Schéma pro vytváření testových šablon

12


3.4

Druhy testů

Systém umožňuje studentům generovat dva druhy testů. Ostrý test je takový, který se započítává do celkového hodnocení studenta. Takovýto test může být jedním studentem generován podle konkrétní šablony pouze jedenkrát. Zkušební test může student generovat tolikrát, kolikrát uzná za vhodné, a proto se výsledky těchto testů do výsledného hodnocení nezapočítávají. Zkušební testy slouží pro procvičení vyučované látky. Konfigurací systému lze generování zkušebních testů povolit nebo zakázat.

3.5

Hodnocení studentů

Důležitou vlastností systému je zpracování výsledků testů a promítnutí těchto výsledků do studentova hodnocení. V tomto směru nabízí systém řadu možností jak hodnocení určovat. Zadání diplomové práce klade požadavek na velkou flexibilitu v nastavování parametrů otázek. Počítá s tím, že existují otázky různých obtížností. Tuto obtížnost lze ohodnotit různým počtem bodů získaných v případě správné odpovědi. V případě špatné odpovědi student body nezískává. Ovšem neznalost základů problematiky by měla být penalizována důsledněji než pouhým ziskem 0 bodů. Zde by měla být administrátorovi ponechána možnost odečítat od bodů získaných v jiných otázkách. Z tohoto důvodu jsou u každé otázky uváděny dva parametry definující její bodové hodnocení. První specifikuje získané body v případě správné odpovědi, druhý body v případě odpovědi špatné. Z logiky věci vyplývá, že první parametr může nabývat kladných hodnot, kdežto druhý hodnot záporných nebo hodnoty 0. Celková úspěšnost testu je vypočítávána vždy pouze z ostrých testů. Pro způsob výpočtu se nabízí dva přístupy. První přístup bere v úvahu fakt, že studentovo celkové hodnocení testu může nabývat záporných hodnot. Tyto záporné hodnoty jsou přičítány k ostatním testům. Celkový počet získaných bodů se počítá z konečného součtu. Druhý přístup bere v úvahu fakt, že nejhorší hodnocení z jednoho testu je 0 bodů. Pokažený test tak neovlivňuje výsledky z jiných testů. Oba dva přístupy mohou být aplikovány na tři různé skupiny ostrých testů: • První skupina obsahuje pouze ty testy, které pochází ze šablon, jež jsou právě aktivní. • Druhá skupina zahrnuje testy generované ze šablon, které v systému v daný okamžik existují - v aktivním i neaktivním stavu. • Poslední skupina obsahuje všechny ostré testy, dokonce i ty, jejichž šablony byly již ze systému odstraněny. Aplikováním dvou zmíněných přístupů na tyto tři skupiny testů vzniká celkem šest možných hodnocení každého studenta. Z těchto hodnocení může být zvoleno to, které nejlépe vyhovuje konkrétním podmínkám. Možnosti jsou zrekapitulovány následujícím příkladem.

KAPITOLA 3. DEFINICE A SPECIFIKACE POŽADAVKŮ Číslo testu 1 2 3 4

Maximálně dosažitelný počet bodů 10 10 10 10

13 Získaný počet bodů 10 5 -2 10

Tabulka 3.2: Ukázka bodového ohodnocení z příkladu 3.1 Započítávané testy 1. skupina 2. skupina 3. skupina

Hodnocení - 1. přístup maximum získáno úspěšnost 20 3 15 % 30 13 43 % 40 23 58 %

Hodnocení - 2. přístup maximum získáno úspěšnost 20 5 25 % 30 15 50 % 40 25 63 %

Tabulka 3.3: Ukázka výpočtu hodnocení studenta z příkladu 3.1

Příklad 3.1: V uvažované situaci administrátor vytvořil celkem 4 šablony testů. Všechny nastavil jako aktivní, a proto si student mohl ze všech šablon vygenerovat ostrý test. Po složení všech testů dosáhl student hodnocení uváděného v tabulce 3.2. Za nějaký čas administrátor přišel na chybu v šabloně, která generovala test číslo 4 a šablonu odstranil. Zároveň kvůli podezření na generování špatného obrázku deaktivoval šablonu číslo 1, aby tím zamezil dalšímu generování chybných testů. Po těchto akcích systém vypočítává celkové studentovo hodnocení tak, jak je uvedeno v tabulce 3.3.

3.6

Jazykové mutace

Důležitou podmínkou je možnost provozovat systém v různých jazykových mutacích. To ovšem neznamená pouze přeložení systémových textů do jiných jazyků. Systém nabízí možnost, jak vytvářet univerzální šablony, ze kterých si studenti mohou generovat testy v různých jazycích. Tyto mutace musí být tedy možné vytvářet pro znění zadání otázek i znění odpovědí.

3.7

Bezpečnost systému

Systém musí zaručit takové podmínky, aby studenti nemohli zneužívat operací, které systém nabízí, a zlepšovat tak své celkové hodnocení. Zvláště důležitá je kontrola operací, které generují testy. Zde je třeba zaručit, aby student mohl generovat skutečně jen jeden ostrý test. Neméně důležitá pozornost musí být věnována také těm akcím, které jakýmkoli způsobem ovlivňují podobu testu po vypršení časového limitu k těmto změnám určenému. V neposlední řadě je třeba zabezpečit detaily uživatelů, které mají zůstat skryty jiným uživatelům.

14

3.8


Správa systémových zdrojů

Šablony otázek mají možnost používat systémové zdroje v podobě obrázků a zásuvných modulů otázek. Aby bylo možné zamezit existenci neplatných odkazů na tyto zdroje, nabízí systém nástroje, kterými je možné tyto odkazy kontrolovat.

Kapitola 4 Tvorba analytického modelu V této kapitole jsou představeny nejdůležitější analytické modely, které slouží ke snadnějšímu pochopení a návrhu systému. Při návrhu těchto modelů je třeba pečlivě zvažovat veškeré požadavky, které od systému očekáváme, jelikož pozdější změna a zapracování těchto, byť sebemenších detailů, může mít značný vliv na celkovou délku vývoje aplikace.

4.1

Relační model

Systém ke svému běhu potřebuje úložiště dat, které nabízí rychlé vyhledávání, snadnou modifikaci a vytváření nových záznamů. Všechny tyto aspekty splňují systémy, které jsou navrženy pro spolupráci s datovými strukturami definovanými pomocí relačního modelu dat. Relační model přináší celou řadu výhod, zejména mnohdy přirozenou reprezentaci zpracovávaných dat, možnost snadného definování a zpracování vazeb apod. Relační model klade velký důraz na zachování integrity dat. Zavádí pojmy jako referenční integrita, cizí klíč, primární klíč apod. Relační model systému SyVyKoD je složen z několika entit, které jsou zobrazeny na obrázku 4.1. Pro definování vztahů je zvolena binární notace zápisu. Vztahy mezi entitami jsou značené čarami. Plné čáry jsou použity tam, kde primární klíč otcovské entity přechází do části primárního klíče entity závislé. Čárkované čáry jsou použity v opačném případě. Povinné členství ve vztahu je značeno krátkou čárkou, nepovinné členství prázdným kolečkem. Rozvětvení čáry představuje vícenásobnou účast ve vztahu. V následujícím textu jsou použité entity stručně popsány a zároveň budou představeny i jiné způsoby, jakými je možné strukturu entit a jejich vztahů navrhnout. User Entita User shromažďuje informace o uživatelích systému. Každý uživatel vlastní své přihlašovací jméno. K ověření pravosti uživatele slouží heslo. Dále může mít uživatel nastaveno jméno, příjmení, email a členství k nějaké skupině uživatelů. Group Entita Group udržuje informace o existujících skupinách uživatelů v systému. Question template V entitě Question template jsou uchovávány otázkové šablony. Question template text Tato entita shromažďuje jazykové mutace zadání otázek. 15

16

KAPITOLA 4. TVORBA ANALYTICKÉHO MODELU

Obrázek 4.1: E-R model systému SyVyKoD


17

Log K uchovávání záznamů o událostech systému slouží entita Log. Answer template U všech šablon typu Static musí administrátor do systému vkládat odpovědi, ze kterých je při generování testových otázek část vybrána a v testu použita. Entita Answer template udržuje seznam všech odpovědí. Answer template text Pro uložení jazykových mutací odpovědí je využita entita Answer template text. Category Entita Category udržuje informace o existujících kategoriích. Tato entita nemá ekvivalent k Question template text. Je to z toho důvodu, že kategorie nejsou pro uživatele viditelné. Proto není třeba jejich názvy překládat. Test template Entita Test template udržuje informace o testových šablonách. Test category Entita Test category pouze umožňuje existenci vícenásobných vztahů entit Test template a Category. Test template text Entita Test template text udržuje jazykové překlady názvů testových šablon. Test Entita Test shromažďuje všechny testy, které v systému existují. Testy mají vazbu na testové šablony, ze kterých vznikly. Informace obsažené v této entitě představují obecné údaje o testu. Mezi důležité patří příslušnost ke studentovi, který test vygeneroval a začátek a doba trvání testu, z nichž se odvozuje časový limit na vypracování testu. Test question Tato entita shromažďuje testové otázky, ze kterých je test složen. Podle typu jsou pak studentovy odpovědi uloženy v entitě Answer 1 nebo v entitě Answer 2. Answer 1 Entita Answer 1 uchovává studentovy odpovědi na otázky generované šablonou s vlastností Option.

18


Answer 2 Entita Answer 2 uchovává studentovy odpovědi na otázky generované šablonou s vlastností AnswerText. Popsaná podoba modelu není jediná možná. Cest, jak model navrhnout, je v případě systému SyVyKoD více. V následujícím textu jsou naznačeny některé další varianty, které by bylo možné při návrhu použít. U každé varianty jsou uvedeny její výhody a nevýhody.

4.1.1

Závislost mezi otázkou a její šablonou

Z modelu 4.1 je patrné, že při generování testových otázek dochází ke kopírování některých atributů ze šablon do testových otázek. Tím dochází k vytváření jisté redundance dat. Tato akce má ovšem za následek odstranění závislosti mezi otázkou a její šablonou. Pokud by při generování měla tato závislost zůstat zachována, musel by se model změnit tak, že by byl do otázky přidán odkaz na příslušnou šablonu. To by se projevilo přidáním cizího klíče. Toto řešení by odstranilo část redundance. Použitý model však oproti této variantě nabízí několik výhod. Předně to jsou regulérní podmínky skládání testů. Jaké následky by mělo použití zmíněného řešení ukazuje příklad 4.1.

Příklad 4.1: Administrátor vytvoří šablonu otázky, která testuje studenty ze znalosti operace součtu v závislosti na dvou sčítancích. Student, který si vygeneruje test obsahující tuto otázku, odpoví správným výsledkem. Tato otázka by tudíž měla být vyhodnocena jako správně zodpovězena. Ovšem administrátor může zadání v šabloně (a tudíž v uvažovaném případě i v otázce) změnit (například z důvodu nalezení chyby v textu) a s ním i hodnotu některého ze sčítanců. Od této chvíle se studentova odpověď vyhodnotí jako chybná. Podobný příklad lze použít i pro atributy udávající počty bodů za správnou a špatnou odpověď. Jestliže test uvádí nějaké podmínky, které prezentuje studentovi, měly by tyto podmínky zůstat zachovány i nadále. Z tohoto důvodu není nastíněné řešení použito. Místo toho systém odděluje šablony od otázek. Tento fakt zajišťuje, že vyhodnocovány budou odpovědi přesně na ty otázky, které byly součástí testu v době jeho vypracování. To ovšem neznamená, že by administrátorovi nebyla ponechána možnost úpravy zadání otázek v budoucnu generovaných. Administrátor může v šablonách otázek upravovat nejen zadání, ale i ostatní atributy. Změny se však promítnou až do nově vygenerovaných testů. Staré zůstanou nezměněny. Ve prospěch použité varianty přispívá i fakt, že systém je navrhován řádově pro desítky až stovky studentů. V takovémto počtu není redundance způsobená kopírováním studentů nijak závažná.

KAPITOLA 4. TVORBA ANALYTICKÉHO MODELU 4.1.2

19

Jazykové mutace

Systém umožňuje vytváření šablon v různých jazykových mutacích. Nejsnazší cesta k poskytování těchto mutací by spočívala ve vytvoření několika tematicky shodných šablon v různých jazycích. Zároveň by v systému existovalo několik kategorií, které by se týkaly stejného tématu, avšak sdružovaly by pouze šablony jedné jazykové mutace. Tyto kategorie by se dále sdružovaly do jednojazyčných šablon testů atd. Popsané řešení je značně neefektivní a má hned několik nevýhod. Administrátor by musel vícekrát zadávat stejné hodnoty atributů pro několik tematicky shodných šablon. Tyto informace by se v databázi zbytečně duplikovaly. Dále by nastával problém s automatickým hodnocením, kde by bylo obtížné rozlišit, které kategorie testů již student vypracoval a které ne. Z tohoto důvodu systém využívá jiné řešení. Atributy každé šablony se do systému zadávají pouze jednou. Jestliže je nutná existence otázky i v jiných jazycích, administrátor může šabloně přidat jazykový překlad. Ten se ovšem ukládá v jiné entitě než hodnoty zbylých atributů. Proto nedochází ke zbytečné redundanci. Toto řešení operuje s tzv. implicitním zněním otázky. Jelikož je rozumné předpokládat, že každá otázka bude mít zadání alespoň v jednom jazyce1 , je entita otázek navržena tak, že sama obsahuje toto implicitní znění. Pokud je aplikace provozována v jednojazyčném prostředí, je šablona kompletní a není zapotřebí nic přidávat. Pokud je prostředí vícejazyčné, doplní administrátor příslušnou jazykovou mutaci. Jestliže se při generování testu vyskytne požadavek na generování otázky v jazyce, který šablona podporuje, bude otázka do testu začleněna v tomto jazyce. Pokud šablona požadovanou jazykovou mutaci nepodporuje, vytvoří se otázka v jazyce implicitním. Analogický postup je aplikován i při vytváření odpovědí u šablon s vlastností Static. Tento přístup má ještě jednu výhodu oproti prvně zmíněnému návrhu. Často se stává, zvláště pak u otázek s vlastností Option, že obsah odpovědí není závislý na jazykové mutaci - je ve všech jazykových mutacích totožný. Může se jednat například o binární výstup algoritmu. V takovýchto případech není nutné, aby administrátor zadával odpovědi ve všech jazykových mutacích, ale stačí uvést odpověď pouze jednou, v implicitní jazykové mutaci. Popsaný mechanizmus pak zajistí, že se při absenci požadované mutace použije mutace implicitní, tudíž ta s textem nezávislým na zvoleném jazyce.

4.2

Funkční model

Modelování případů užití je jednou z forem, jak získávat přehled o požadavcích, které jsou na systém kladeny. Jedná se o doplňkový způsob vzhledem k specifikaci požadavků, jež byla popsána v předchozí kapitole. Modelování případu užití používá objekty známé pod těmito názvy: • Účastníci. To jsou role přidělené osobám nebo předmětům využívající systém. 1

Většinou v jazyce prostředí, ve kterém je aplikace provozována

20

KAPITOLA 4. TVORBA ANALYTICKÉHO MODELU • Případy užití(use cases). Činnosti, které systém umožňuje provádět. • Relace. Vztahy mezi účastníky a případy užití. • Hranice systému. Hranice, jež vymezuje funkčnost systému.

Na obrázku 4.2 je znázorněn model případu užití pro systém SyVyKoD. Představuje 3 aktéry - Student, Neregistrovaný uživatel a Administrátor. Každý z nich je spojen s konkrétním případem užití. Diagram přehledně zobrazuje základní funkce systému.

Obrázek 4.2: Model případu použití (Use Case diagram) systému SyVyKoD

Další částí analýzy jsou funkční datové toky. Na obrázcích 4.3, 4.4 a 4.5 jsou postupně znázorněny datové toky v závislosti na aktivitách pro neregistrovaného uživatele, studenta a administrátora. Neregistrovaný uživatel má právo pouze na prohlížení vizualizačních appletů znázorňující činnost kompresních algoritmů. Student může v systému vystupovat pod uživatelským jménem, může procházet svá osobní nastavení a hlavně může skládat administrátorem připravené testy. Po dokončení má možnost nechat testy automaticky vyhodnotit a zobrazit si své hodnocení. Osobní údaje ani hodnocení jiných uživatelů mu nejsou přístupné. Administrátor má právo vidět údaje ostatních uživatelů. Jeho hlavním úkolem je vytváření šablon, ze kterých si uživatelé generují vlastní testy. Administrátor má také možnost


21

testy upravovat, mazat z nich jednotlivé testové otázky a nastavovat časový měřič limitu na vypracování testu.

Obrázek 4.3: Diagram datových toků - Neregistrovaný uživatel

Obrázek 4.4: Diagram datových toků - Student

4.3

Dynamický model - životní cyklus testu

Reakce systému v závislosti na akcích uživatelů jsou velice podobné běžným aplikacím stejného typu. Proto není zapotřebí tyto triviální reakce systému rozvádět. Výjimku tvoří životní cyklus testu, který ovlivňuje značnou část uživatelských akcí. Jak bylo již dříve zmíněno, testy se generují z předpřipravených testových šablon. Od vygenerování až po ohodnocení prochází test několika fázemi, které se od sebe navzájem liší tím, jak je možné v těchto fázích s testem pracovat.

22


Obrázek 4.5: Diagram datových toků - Administrátor

1. fáze - Aktivní šablona Tato fáze reprezentuje období testu před jeho vznikem. Jakmile administrátor sestaví testovou šablonu a označí ji jako aktivní, může student použít tuto šablonu pro vygenerování testu. Šablony, které nejsou aktivní, jsou pro studenta skryté, a proto z nich testy generovat nemůže.

2. fáze - Aktivní test V době generování nového testu se z parametrů testových otázek vypočítá časový interval potřebný na vypracování testu. Po tento interval bude test aktivní a bude patřit do 2. fáze životního cyklu. Po celou dobu této fáze je student oprávněn odpovídat na testové otázky a to dokonce i po odhlášení a opětovném přihlášení do systému. Po uplynutí času stanoveného na vypracování přechází test automaticky do 3. fáze. Pokud student dokončí test dříve než vyprší limit, může si nechat test vyhodnotit a tím přeskočit 3. fázi cyklu a přemístit ho přímo do 4. fáze.


23

3. fáze - Test čekající na vyhodnocení Po skončení časového limitu již není možné dále test upravovat ani prohlížet2 . Test se nachází ve stavu, kdy čeká na vyhodnocení testových otázek. Tuto akci může provést student kdykoli. Pokud test není ohodnocen, nezapočítávají se výsledky do celkového hodnocení studenta. Administrátor má možnost obnovit časový měřič testu. Tato volba může být užitečná v případě, kdy student neměl možnost regulérně test dokončit. Příkladem mohou být technické problémy připojení k systému apod. Po obnovení měřiče přechází test do 2. fáze Aktivní test a student může dokončit skládání testu. Zároveň platí, že administrátor má možnost test kdykoli ze systému odstranit a tím dát opět studentovi možnost ostrý test z této šablony generovat. 4. fáze - Kompletní Test Po vyhodnocení testu už samozřejmě nelze test dále upravovat. Je možné ho pouze prohlížet. U vyhodnocených otázek je zvýrazněno, zda student odpověděl na otázku správně či špatně. Zároveň má student k dispozici i správné řešení. Všechny ostré testy, které se nacházejí v této fázi, jsou započítávány do výsledného hodnocení. Celý životní cyklus testu je zobrazen pomocí dynamického modelu na obrázku 4.6. Výrazně jsou značeny ty stavy, které představují jednotlivé fáze životního cyklu. Pro přesnost je třeba dodat, že v diagramu není značena možnost odstranění testu. Tato akce může být provedena pouze administrátorem a to v každém ze stavů, v kterých se může test nacházet. Akce není do diagramu zanesena z důvodu zvýšení jeho přehlednosti.

2

Toto pravidlo se nevztahuje na administrátora

24


Obrázek 4.6: Dynamický model životního cyklu testu

Kapitola 5 Návrh systému Tato kapitola popisuje hlavní body návrhu systému SyVyKoD. Je rozdělena do dvou hlavních částí. První popisuje návrh modulu pro vizualizaci kompresních algoritmů. Druhá část se zabývá návrhem modulu pro testování studentů.

5.1

Modul pro prezentaci kompresních algoritmů

Hlavním cílem této části je vytvoření šablony XHTML dokumentu, který bude studentům předmětu Komprese dat sloužit k vytváření prezentací kompresních algoritmů. U každé ukázky algoritmu je uveden jeho krátký popis vlastností, činnosti a především applet, který vizualizuje proces komprese a dekomprese zadaného vstupního textu. Tyto applety jsou vytvářeny v rámci semestrálních prací a navazují na diplomovou práci [1]. Dalším úkolem je návrh struktury webových stránek, které semestrální práce prezentují. Při návrhu přichází v úvahu dvě možnosti řešení. První z nich, která by seskupovala modul pro prezentaci algoritmů a modul pro testování studentů v jeden celek, může využívat výhod dynamického webu, což by pomohlo obzvláště při realizaci navigace mezi jednotlivými ukázkami algoritmů. Jako lepší se však ukázala možnost druhá, která rozděluje oba moduly na dva na sobě zcela nezávislé celky. Modul pro prezentaci algoritmů tak může být realizován formou statických webových stránek, což ho činí nezávislým na aplikačních serverech a webových službách a může být tudíž provozován i lokálně na offline PC stanici. Web existuje ve dvou jazykových variantách - české a anglické. Navržení kostry modulu umožňuje přepnutí jazyka v libovolné době při zachování zobrazovaného tématu. 5.1.1

Struktura modulu

V následujícím textu je popsána struktura modulu. img ALG1 index_cs.html index_en.html ALG1.jar ALG2 ... styl.css compression.jar epsgraphics.jar

-

adresář s obrázky adresář algoritmu ALG1 český popis algoritmu anglický popis algoritmu vizualizační applet algoritmu ALG1 adresář algoritmu ALG2

- specifikace grafického vzhledu - základní balíček pro vizualizační applety - balíček pro výstup obrázků v postskriptovém formátu 25

26

KAPITOLA 5. NÁVRH SYSTÉMU streams.jar index.html index_en.html obsah.html content.html

-

balíček pro podporu kompresních proudů úvodní strana v češtině úvodní strana v angličtině přehled všech dostupných algoritmů v češtině přehled všech dostupných algoritmů v angličtině

Soubory compression.jar a streams.jar jsou archivy podporující vývoj aplikací zabývajících se kompresí dat. Konkrétně se jedná o základní třídy pro vytváření vizualizačních appletů. Jednotlivé vizualizační applety jsou uloženy v adresářích pojmenovaných podle názvu algoritmu. V adresářovém výpisu slouží jako ukázka algoritmu adresář ALG1, který obsahuje XHTML dokumenty pro popis algoritmu a JAR archiv s vizualizačním appletem.

5.2

Modul pro testování studentů

Dobrý návrh struktury, objektů a vztahů mezi nimi je velice důležitý pro celkový vývoj modulu. Pokud k odhalení nedostatků systému dojde už ve fázi návrhu, je jeho změna méně bolestivá než v následujících fázích vývoje. Až doposud nebylo zapotřebí specifikovat na jakých konkrétních technologiích bude systém postaven. V tomto stupni vývoje je však třeba učinit rozhodnutí, které ovlivní jeho další směr. Odborná literatura uvádí, že i fáze návrhu má být pokud možno nezávislá na prostředcích konečné implementace. V tomto případě je návrh specifický natolik, že další abstraktní pohled na věc by byl nepřínosný. V následujícím textu bude nastíněna podoba aplikace do té míry, aby bylo možné provádět její další návrh. 5.2.1

Typ aplikace

Modul pro testování studentů je realizován jako webová aplikace založená na Java 2 Platform Enterprise Edition (J2EE). J2EE je standardní součástí Javy. Platforma Java byla vybrána kvůli výhodám, které nabízí. Jedná se o perspektivní objektový programovací jazyk. Je vyvíjen společností SUN Microsystems a je zdarma dostupný pro různé operační systémy (Windows, Linux, Solaris atd.) Nezávislost na operačním systému a na hardwaru počítače zajišťuje způsob kompilace. Zdrojové kódy programu nejsou překládány do strojového kódu procesoru, ale pouze předzpracovávány do tzv. byte-kódu. Ten ještě není závislý na konkrétním procesoru, ale časově náročné fáze kompilace jsou v něm již provedeny. Při spuštění Java programu je byte-kód interpretován virtuálním strojem Java Virtual Machine (JVM). Java tedy patří do skupiny interpretovaných jazyků. J2EE je množina specifikací a praktik, které dohromady poskytují řešení pro vývoj, rozmístění a řízení vícevrstvých serverových aplikací. J2EE vychází z Java 2 Standard Edition (J2SE), k níž přidává vlastnosti potřebné pro poskytnutí stabilní, bezpečné a rychlé Java platformy na úrovni podnikových aplikací. Mezi tyto vlastnosti patří například zpracování událostí na straně serveru, řízení transakcí, databázové služby a další. Platforma J2EE zpřístupňuje podnikové aplikace širokému spektru klientů včetně internetových prohlížečů. Spojuje celou řadu

KAPITOLA 5. NÁVRH SYSTÉMU

27

technologií do jediné architektury s komplexním modelem programování aplikací. Platforma J2EE podstatně zjednodušuje vývoj síťových aplikací a snižuje jeho náklady. Modul pro testování (dále označován jako webová aplikace) nevyužívá všech dostupných součástí J2EE, ale zaměřuje se na použití servletů a JSP stránek. Servlet je obdoba CGI skriptu napsaná v Javě. Je to třída odvozená z třídy javax.servlet.http.HTTPServlet. Oproti CGI skriptům má několik výhod. Servlet je jednou zkompilován a načten do paměti. Potom už jenom odpovídá na požadavky klientů (takže je rychlejší než PHP, CGI nebo ASP). Jelikož je servlet program psaný v Javě, má přístup k většině Javovských knihoven. Servlet běží v servlet kontejneru aplikačního serveru. JSP je technologie založená na servletech, která jejich použití velice zjednodušuje a tím zrychluje vývoj webových aplikací. Další výhoda, kterou JSP mají, je oddělení obsahu od zpracování. Pro tyto účely používají JSP tzv. javabeans a uživatelské tagy. JSP technologie umožňuje směšovat statické HTML stránky s dynamicky generovaným obsahem. JSP stránky je možno používat i samostatně, ale podstatně lepší využití se nabízí ve spolupráci se servlety. Použití servletu je totiž poměrně obtížné pro vytváření statického HTML kódu. JSP se proto používá ke směšování statických částí HTML stránek, které jsou napsány v klasickém HTML kódu, s dynamickými částmi, které jsou vytvářeny pomocí servletu. 5.2.2

Návrh struktury aplikace

Při návrhu systémů je výhodné používat osvědčené postupy, kterým se říká návrhové vzory. Tyto postupy jsou dostatečně propracované a pomáhají k modularizaci systému a tím i k jeho lepšímu pochopení. Systém SyVyKoD ve svém návrhu používá několik takovýchto vzorů. Celý systém je navržen podle modelu MVC - Model-View-Controller. MVC (někdy také označován jako Model-2) je softwarová architektura, která rozděluje datový model aplikace, uživatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní. Komponenty MVC mají následující funkce: • Komponenta Model představuje specifickou reprezentaci informací, s nimiž aplikace pracuje. • Komponenta View převádí data reprezentovaná modelem do podoby vhodné k interaktivní prezentaci uživateli. • Komponenta Controller reaguje na události (typicky pocházející od uživatele) a zajišťuje změny v komponentě model nebo v komponentě view. Použití tohoto návrhového vzoru v systému SyVyKoD je znázorněno na obrázku 5.1. Obrázek představuje obecný model, podle kterého je postavena celá aplikace. Aplikace je řízena požadavky uživatelů. Na každý HTTP požadavek je vygenerována HTTP odpověď, která je zaslána zpět uživateli. Požadavky přijímá controller, který je v aplikaci reprezentován servlety zvanými dispatchery. Dispatcher má za úkol rozhodnout, zda je přijímaný požadavek platný či nikoli. Jestliže ano, servlet extrahuje parametry předávané v HTTP požadavku. Podle těchto

28


parametrů zavolá příslušnou akci objektu BackingBean a předá mu extrahované parametry. BackingBean má za úkol připravit data pro komponentu view. Pokud má prováděná akce změnit datový model, BackingBean vytvoří objekt JavaBean, který slouží pouze jako kontejner pro přenášená data. Tento kontejner je zaslán komponentě model, která podle předávané JavaBeany provede příslušné změny v datovém modelu.

Obrázek 5.1: Použití návrhového vzoru MVC v základní struktuře aplikace

Komponenta model se skládá z několika vrstev. Nejspodnější vrstvu tvoří datový zdroj1 , který uchovává data systému. S datovým zdrojem komunikují tzv. DAO (data access object) objekty, které slouží jako rozhraní mezi datovým zdrojem a zbytkem aplikace. Použitím DAO objektů je docíleno odstínění aplikační logiky od perzistentní vrstvy, což mimojiné umožňuje i snadnou výměnu datového zdroje bez zásahu do jiných komponent než DAO objektů. Každý DAO objekt je spjatý s jednou z databázových entit popsaných v relačním modelu dat. Jelikož jedna akce může ovlivňovat více entit najednou, je na rozhraní mezi komponentou controller a komponentou view zařazen ještě jeden typ objektů, který se nazývá DatabaseBean. Ten má za úkol reagovat na požadavky od BackingBean a provádět změny v modelu s využitím přesně těch DAO objektů, které jsou k provedení akce potřeba. Z komponenty model proudí data opět zapouzdřená v JavaBeanech zpět do komponenty controller. Podle výsledku prováděné akce objekt BackingBean určí, jak se komponenta view změní. Jinými slovy řečeno, BackingBean vybere JSP stránku, která bude uživateli ve formě HTTP odpovědi odeslána. Pak předá řízení opět servletu. Ten už jen zařídí přesměrování HTTP 1

Datový zdroj je v nejčastějších případech reprezentován databázovým serverem


29

požadavku na příslušnou JSP stránku. JSP stránky představují komponentu view. Při generování XHTML kódu si JSP stránky od objektu BackingBean vyžádají připravená data. Ta jsou jím uchovávána po zbytek doby trvání HTTP požadavku. Odesláním HTTP odpovědi ve formě vygenerované XHTML stránky životnost požadavku končí. Komponenta view neslouží v systému pouze jako interpret dat, ale zároveň jako rozhraní pro zadávání uživatelských požadavků. Toto rozdělení aplikace zajišťuje přehlednost a jasné přiřazení úloh jednotlivým komponentám. Pro zpřehlednění textu byly některé klíčové úlohy jednotlivých komponent vynechány. Následující text ve stručnosti zrekapituluje všechny podstatné komponenty a vyjmenuje jejich hlavní úkoly. Servlet přijímá požadavky od uživatelů. Pokud je požadovaný zdroj dostupný pouze přihlášeným uživatelům, kontroluje zda uživatel přihlášený je či není. Z přijatých parametrů určí požadovanou akci a zavolá ji. Objekt BackingBean, který akci provádí, zkontroluje, zda má přihlášený uživatel oprávnění k vykonávání této akce. Pokud ano, tuto akci provede. Pokud ne, pak se jako cílová označí JSP stránka, která informuje o neprivilegovaném přístupu. Většina prováděných akcí spolupracuje s komponentou model. Z této komponenty přicházejí data ve formě JavaBeanů. Ty jsou uchovány v objektu BackingBean pro JSP stránku. Po vykonání akce přesměruje servlet požadavek na příslušnou JSP stránku. Ta vygeneruje XHTML stránku podle dat z JavaBeanů. Z takto navržené struktury vyplývá, že všechny akce, které lze v systému provádět, jsou prováděny v objektech BackingBean. Z tohoto důvodu jsou tyto objekty vhodné pro zaznamenávání událostí systému - tzv. logování.

Kapitola 6 Realizace Tato kapitola popisuje řešení a prostředky zvolené při implementaci systému. Je rozdělena do dvou hlavních částí. První část popisuje modul pro prezentaci kompresních algoritmů. Druhá, rozsáhlejší, je věnována modulu pro testování studentů. Na úvod každé části jsou vyjmenovány potřebné softwarové produkty, bez kterých není možné systém provozovat. Dále následuje popis použitých technologií a v závěru jsou popsány ty části, které jsou z implementačního hlediska zajímavé a netriviální.

6.1

Modul pro prezentaci kompresních algoritmů

Šablony ukázek algoritmů a struktura webových stránek jsou popsány v předchozí kapitole. Následující text představuje technologie použité při vytváření tohoto modulu.

6.1.1

Použité technologie

Prezentace je realizována pomocí XHTML stránek, které jsou psány tak, aby vyhovovaly standardu XHTML 1.0 ve variantě Transitional. Přestože „čistšíÿ přístup by spočíval v použití varianty Strict, v případech, kdy je do stránky vkládán applet, je nutné použít variantu Transitional. Varianta Strict totiž ve svém DTD použití tagu ... nepovoluje. Tento tag by měl být nahrazován obecným tagem , avšak doposud je jeho podpora v různých prohlížečích odlišná, a proto jeho použití přináší celou řadu problémů1 . Podoba XHTML dokumentu představující šablonu pro prezentaci algoritmů je k dispozici na CD přikládaném k diplomové práci.

6.1.2

Grafický vzhled

Jednotný grafický vzhled stránek je zajištěn pomocí kaskádových stylů uložených v externím souboru. To přináší výhodu snadné a hromadné modifikace. Pomocí kaskádových stylů lze také snadno ovlivnit odlišný vzhled pro různé jazykové mutace. To je vhodné například k zobrazování odstavců podle národních zvyklostí. Dokument XHTML umožňuje svým atributem xml:lang specifikovat jazyk, který je v dokumentu použit. V kaskádových stylech je možné s touto informací pracovat pomocí pseudo-třídy :lang. Zkombinováním těchto prostředků lze specifikovat vzhled dokumentu odvislý od jazykové mutace bez potřeby změny základní struktury XHTML stránek. 1 Řešení by spočívalo v detekci prohlížeče skriptovacím jazykem a přizpůsobením tagu

Elektronická podpora výuky předmětu Komprese dat

Recommend Documents

Výstupní řetězec