Systém pro odevzdávání studentských prací. Bc. Radek Malinský

ˇ Ceské vysoké uˇcení technické v Praze Fakulta elektrotechnická

ˇ VUT FEL katedra pocˇı´tacˇu˚ C

Diplomová práce

Systém pro odevzdávání studentských prací Bc. Radek Malinský

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

Studijní program: Elektrotechnika a informatika, strukturovaný magisterský Obor: Výpoˇcetní technika kvˇeten 2009

Podˇekování Velmi rád bych podˇekoval a vyslovil uznání všem, kteˇrí se podíleli na vzniku této práce. Pˇredevším vedoucímu diplomové práce Ing. Miroslavu Balíkovi, Ph.D., za trpˇelivost a pevné nervy pˇri vedení a poskytování praktických rad. Dále bych rád podˇekoval mé rodinˇe a pˇrátelum, ˚ kteˇrí mˇe podporovali a neustále pˇricházeli s novými nápady na zlepšení. ii

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatnˇe a použil jsem pouze podklady uvedené v pˇriloženém seznamu. Nemám závažný duvod ˚ proti užití tohoto školního díla ve smyslu §60 Zákona cˇ . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmˇenˇe nˇekterých zákonu˚ (autorský zákon).

V Praze dne 1. 5. 2009

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

iii

Abstract This master thesis discusses the creation software interface of web application for student projects uploading. The main part describes design and implementation of the application using Java EE technology. The main contribution is a transformation of object model to the relational schema. Next part is focused on using of the source code validation service that can to check syntactical and semantical correctness, and also checks the source code validity. Last part deals with design and implementation of the program unit focused to searching duplicities between uploaded works.

Abstrakt Tato diplomová práce se zabývá tvorbou softwarového rozhraní webové aplikace pro odevzdávání studentských prací. Hlavní cˇ ást popisuje návrh a realizaci aplikace za pomoci technologií Java EE. Pˇredevším se vˇenuje vytvoˇrení relaˇcního databázového schématu z objektového modelu. Další cˇ ást je zamˇerˇena na použití validátoru zdrojových kódu, ˚ který mimo syntaktických a sémantických pravidel kontroluje také funkˇcní správnost kódu. Poslední cˇ ást uvádí návrh a realizaci modulu pro vyhledávání duplicitních prací mezi odevzdanými zdrojovými kódy. iv

Obsah Seznam obrázku˚

viii

Seznam tabulek

ix

1 Úvod 1.1 Duvody ˚ vzniku systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1

2 Popis problému, specifikace cíle 2.1 Popis rˇešeného problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Vymezení cílu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 2

3 Analýza a návrh rˇešení 3.1 Výbˇer implementaˇcního prostˇredí . . . . . . . . . 3.1.1 Java Enterprise Edition . . . . . . . . . . . . 3.1.1.1 Prezentaˇcní vrstva . . . . . . . . . 3.1.1.2 Aplikaˇcní vrstva . . . . . . . . . . 3.1.1.3 Vrstva persistence dat . . . . . . . 3.1.2 JavaServer Pages . . . . . . . . . . . . . . . 3.1.2.1 Skriptovací znaˇcky . . . . . . . . 3.1.2.2 Knihovny znaˇcek . . . . . . . . . 3.1.3 JavaServer Faces . . . . . . . . . . . . . . . 3.1.3.1 Životní cyklus JSF . . . . . . . . . 3.1.3.2 Navigace v JSF . . . . . . . . . . . 3.1.4 Java Beans . . . . . . . . . . . . . . . . . . . 3.1.4.1 Java Beans a JSF . . . . . . . . . . 3.1.5 ICEfaces . . . . . . . . . . . . . . . . . . . . 3.1.5.1 ICEfaces architektura . . . . . . . 3.1.6 Hibernate . . . . . . . . . . . . . . . . . . . 3.1.6.1 Java Persistence API . . . . . . . . 3.1.6.2 Anotace . . . . . . . . . . . . . . . 3.1.6.3 Entity Manager a práce s objekty 3.1.6.4 Životní cyklus entity . . . . . . . 3.2 Modul vyhledávání duplicitních prací . . . . . . . 3.2.1 Popis modulu . . . . . . . . . . . . . . . . . 3.2.2 Princip funkce . . . . . . . . . . . . . . . . . 3.3 Modul importování uživatelu˚ . . . . . . . . . . . . 3.3.1 Popis modulu . . . . . . . . . . . . . . . . . 3.3.2 Uživatelské role . . . . . . . . . . . . . . . . 3.3.2.1 Role Student . . . . . . . . . . . . 3.3.2.2 Role Uˇcitel . . . . . . . . . . . . . 3.3.2.3 Role Administrátor . . . . . . . . 3.3.2.4 Role Super uživatel . . . . . . . . 3.3.3 XML šablona . . . . . . . . . . . . . . . . . 3.4 Validátor zdrojových kódu˚ . . . . . . . . . . . . . . 3.4.1 Popis validátoru . . . . . . . . . . . . . . . 3.4.2 Princip funkce validátoru . . . . . . . . . . 3.4.3 Konfigurace validaˇcního serveru . . . . . . 3.4.4 Konfigurace domény . . . . . . . . . . . . . v

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 3 3 4 4 4 4 4 5 6 6 7 8 9 10 10 11 11 11 12 13 14 14 14 15 15 15 15 15 15 15 16 17 17 18 19 20

4 Realizace 4.1 Návrh databáze . . . . . . . . . . . . . . . . . . . 4.1.1 Konfigurace JPA . . . . . . . . . . . . . . 4.1.2 Vytvoˇrení entity . . . . . . . . . . . . . . . 4.2 Modul vyhledávání duplicitních prací . . . . . . 4.2.1 Realizace 1. úrovnˇe vyhledávání . . . . . 4.2.2 Realizace 2. úrovnˇe vyhledávání . . . . . 4.2.2.1 Odstranˇení komentáˇru˚ . . . . . 4.2.2.2 Odstranˇení ostatních vlastností 4.2.3 Realizace 3. úrovnˇe vyhledávání . . . . . 4.3 Modul importování uživatelu˚ . . . . . . . . . . . ˇ 4.3.1 Ctení XML šablony . . . . . . . . . . . . . 4.4 Validátor zdrojových kódu˚ . . . . . . . . . . . . . 4.4.1 Zaslání souboru˚ k validaci . . . . . . . . . 4.5 Uživatelské rozhraní . . . . . . . . . . . . . . . . 4.5.1 Autentizace uživatele . . . . . . . . . . . 4.5.1.1 Autentizaˇcní skript . . . . . . . 4.5.1.2 Spuštˇení autentizaˇcního skriptu 4.5.2 Lokalizace do více jazyku˚ . . . . . . . . .

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

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

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

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

5 Testování 5.1 Cíl testování . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Hypotézy . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Pˇríprava na testování . . . . . . . . . . . . . . . . . . . . 5.4 Harmonogram testování . . . . . . . . . . . . . . . . . . 5.5 Získání zpˇetné vazby . . . . . . . . . . . . . . . . . . . . 5.6 Skupina testujících uživatelu˚ . . . . . . . . . . . . . . . 5.6.1 Požadované profily testujících osob . . . . . . . 5.6.2 Skuteˇcné profily testujících osob . . . . . . . . . 5.7 Závˇereˇcný dotazník . . . . . . . . . . . . . . . . . . . . . 5.7.1 První cˇ ást dotazníku . . . . . . . . . . . . . . . . 5.7.2 Úˇcel sledování otázek v první cˇ ásti dotazníku . 5.7.3 Druhá cˇ ást dotazníku . . . . . . . . . . . . . . . 5.7.4 Úˇcel sledování otázek ve druhé cˇ ásti dotazníku 5.7.5 Dˇelení uživatelu˚ do skupin . . . . . . . . . . . . 5.8 Prubˇ ˚ eh testu . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.1 Seznámení uživatelu˚ s aplikací . . . . . . . . . . 5.8.2 Testování aplikace . . . . . . . . . . . . . . . . . 5.8.3 Dotazník . . . . . . . . . . . . . . . . . . . . . . . 5.9 Výsledky testu . . . . . . . . . . . . . . . . . . . . . . . . 5.9.1 Pˇrihlášení do systému . . . . . . . . . . . . . . . 5.9.2 Odevzdání první úlohy . . . . . . . . . . . . . . 5.9.3 Odevzdání dalších úloh . . . . . . . . . . . . . . 5.9.4 Dotazník . . . . . . . . . . . . . . . . . . . . . . . 5.9.4.1 Odevzdání první úlohy . . . . . . . . . 5.9.4.2 Zveˇrejnování ˇ testovacích dat . . . . . . 5.9.4.3 Zmˇena vzhledu a pˇridání funkcí . . . . 5.10 Závˇer testování . . . . . . . . . . . . . . . . . . . . . . . 5.10.1 Vyhodnocení hypotéz . . . . . . . . . . . . . . . 5.10.2 Navrhované zmˇeny . . . . . . . . . . . . . . . .

vi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22 22 22 23 24 24 25 25 26 26 26 27 28 28 29 29 29 29 30

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

32 32 32 32 32 33 33 33 33 33 34 35 35 36 36 37 37 37 39 39 39 39 40 41 41 42 43 52 52 53

6 Závˇer a námˇety pokraˇcování práce

54

7 Literatura

55

A Seznam použitých zkratek

57

B Uživatelský manuál B.1 Pˇrihlášení do systému . . . . . B.2 Prostˇredí po pˇrihlášení . . . . . B.3 Odevzdání práce . . . . . . . . B.4 Kontrola odevzdaných prací . . B.5 Zmˇena uživatelského nastavení

. . . . .

59 59 60 60 62 62

. . . . . . . . .

63 63 63 64 64 65 67 69 70 71

. . . . .

. . . . .

. . . . .

C Administrátorský manuál C.1 Pˇrihlášení do systému . . . . . . . . C.2 Nastavení systému . . . . . . . . . . C.3 Vytvoˇrení nového pˇredmˇetu . . . . . C.4 Vytvoˇrení nové množiny úloh . . . . C.5 Vytvoˇrení nové úlohy . . . . . . . . . C.6 Agenda uživatelu˚ . . . . . . . . . . . C.7 Datové seznamy a editace záznamu˚ C.8 Kontrola odevzdaných prací . . . . . C.9 Vyhledávání duplicitních prací . . .

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

D Obsah pˇriloženého CD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

72

vii

Seznam obrázku˚ 3.1 3.2 3.3 3.4

Životní cyklus zpracování událostí v JSF ICEfaces architektura . . . . . . . . . . . Životní cyklus entity . . . . . . . . . . . Proces validace zdrojového kódu . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

7 10 13 18

5.1 5.2 5.3 5.4 5.5

Informace o zpusobu ˚ získání hesla pro pˇrihlášení. Chybné a úspˇešné odevzdání první úlohy. . . . . . Rozdˇelení do skupin podle vˇeku uživatelu. ˚ . . . . ˇ Cetnost odpovˇedí na 2. otázku z II. dotazníku. . . ˇ Cetnost odpovˇedí na 3. otázku z II. dotazníku. . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

39 40 41 42 42

B.1 B.2 B.3 B.4 B.5 B.6

Formuláˇr pro pˇrihlášení do systému Prostˇredí po pˇrihlášení do systému . Výbˇer množiny úloh . . . . . . . . . Výbˇer úlohy . . . . . . . . . . . . . . Kontrola odevzdaných prací . . . . . Zmˇena uživatelského nastavení . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

59 59 60 61 62 62

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11

Formuláˇr pro pˇrihlášení do systému . . . Nastavení systému . . . . . . . . . . . . . Vytvoˇrení nového pˇredmˇetu . . . . . . . . Vytvoˇrení nové množiny úloh . . . . . . . Vytvoˇrení nové úlohy . . . . . . . . . . . . Vytvoˇrení nové validaˇcní úlohy . . . . . . Import uživatelu˚ . . . . . . . . . . . . . . Vytvoˇrení nového uživatele . . . . . . . . Editace záznamu˚ vytvoˇreného pˇredmˇetu Kontrola odevzdaných prací . . . . . . . . Vyhledávání duplicitních prací . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

63 63 64 65 66 67 68 69 70 71 71

. . . . . .

. . . . . .

viii

. . . .

. . . .

. . . .

. . . .

. . . .

Seznam tabulek 5.1 5.2 5.3 5.4 5.5 5.6

Rozdˇelení uživatelu˚ do skupin podle poˇctu bodu˚ z dotazníku. . . . . Bodové ohodnocení otázek ze závˇereˇcného dotazníku. . . . . . . . . Úspˇešnost odevzdání první úlohy. . . . . . . . . . . . . . . . . . . . . Rozdˇelení uživatelu˚ do skupin v závislosti na vyplnˇeném dotazníku. Odpovˇedi na otázky týkající se vylepšení funkˇcnosti a vzhledu. . . . Procentuální rozdˇelení uživatelu˚ do skupin podle zkušeností. . . . .

ix

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

37 38 40 41 51 52

KAPITOLA 1. ÚVOD

1

1 Úvod Pˇri stoupajících požadavcích na praktické znalosti studentu˚ z programování je výhodné jejich znalosti ovˇerˇit, a to i bez pˇrítomnosti dalších osob. ˇ Na Západoˇceské univerzitˇe v Plzni (ZCU) je již nˇekolik let úspˇešnˇe využíván systém, který umožnuje ˇ testování a hodnocení studentských prací. Tento systém se v praxi velice osvˇedˇcil ˇ a nyní jej zavádí i Fakulta elektrotechnická Ceského vysokého uˇcení technického v Praze (FEL ˇ CVUT). Tato diplomová práce se zabývá tvorbou webové aplikace pro odevzdávání studentských ˇ který mimo syntaktických a sémantických pravidel prací. Souˇcástí je validátor dodaný ZCU, kontroluje také funkˇcní správnost kódu. Práce se dále zabývá tvorbou modulu pro vyhledávání duplicitních prací. Nemalá cˇ ást je vˇenována transformaci objektového modelu do relaˇcního databázového schématu. Práce je rozdˇelena do šesti kapitol. První kapitolou je tento úvod zabývající se duvody ˚ vzniku systému, ve druhé kapitole je struˇcný pˇrehled problému˚ týkajících se tvorby práce, tˇretí kapitola je zamˇerˇena na analýzu implementace a návrh rˇešení, cˇ tvrtá kapitola obsahuje podrobný popis metod a funkcí použitých bˇehem realizace, pátá kapitola je vˇenována testování aplikace a šestá kapitola je shrnutím výsledku˚ diplomové práce.

1.1 Duvody ˚ vzniku systému Systém je navržen pˇredevším pro školy a vzdˇelávací instituce, kde je nutné odevzdávat úlohy elektronickou cestou. Pˇríkladem muže ˚ být pˇredmˇet Algoritmizace vyuˇcovaný Katedrou poˇcíˇ taˇcu˚ FEL CVUT. Studenti jsou seznamováni se základy programování a bˇehem semestru odevzdávají domácí úlohy (zdrojové kódy). V souˇcasné dobˇe je každý student nucen odevzdat domácí úlohu emailem. Nemá tak žádnou jistotu, že úloha úspˇešnˇe dorazila. Ale pˇredevším bude o výsledku své práce informován po nˇejakém cˇ ase, až vyuˇcující úlohu pˇrijme a pˇrekontroluje. Každý vyuˇcující muže ˚ vést více než jedno cviˇcení a na každém muže ˚ být až 20 studentu. ˚ Toto pro nˇej pˇredstavuje velké cˇ asové vytížení pˇri zpracování zaslaných prací, pˇri jejich opravování, hodnocení a pˇri zapisování výsledku. ˚ Systém, který by umožnoval ˇ pˇrijmout soubory od více uživatelu˚ a v pˇrípadˇe zdrojového kódu soubor automaticky pˇrekontroloval, ohodnotil a bez prodlení zaslal výsledky uživateli by celou proceduru odevzdání výraznˇe zjednodušil.

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

2

2 Popis problému, specifikace cíle Hlavním cílem práce je vytvoˇrit webový systém pro odevzdávání studentských prací. Systém automaticky pozná, je-li odevzdaná práce zdrojový kód vytvoˇrený v programovacím jazyce Java a umožní jeho kontrolu funkˇcní správnosti pomocí externího validátoru.

2.1 Popis rˇešeného problému Zcela obecnˇe pˇredstavuje odevzdávací systém webovou prezentaci, která umožnuje ˇ odevzdání prací a jejich automatickou kontrolu. V detailním pohledu je to systém, který v sobˇe sdružuje webový, databázový a aplikaˇcní server. Na aplikaˇcním serveru muže ˚ bˇežet nˇekolik podpurných ˚ aplikací, z nichž nejvýznamnˇejší je validaˇcní. Proto je dále v textu aplikaˇcní server oznaˇcován jako validaˇcní. Registrovaný uživatel se do systému pˇrihlašuje pˇres webové rozhraní, kde má možnost odevzdat vypracovanou úlohu. Pokud je úloha programovacího charakteru (zdrojový kód), je automaticky pˇreposlána validaˇcnímu serveru. Ten ji pˇrekontroluje a podle pˇredepsaných kritérií automaticky oboduje. Po uplynutí urˇcitého cˇ asového intervalu (napˇr. semestr) systém seˇcte všechny body a uživatele ohodnotí (napˇr. známkou). Kdykoli musí nˇejaká práce splnovat ˇ urˇcité formální požadavky, je možné na její kontrolu použít validaˇcní systém. Pokud je napˇríklad nutné pˇrijímat jen urˇcité typy souboru˚ se specifickým obsahem nebo tˇreba odevzdané XHTML1 stránky validovat W3C2 validátorem nebo vykonávat plno jiných kontrol, je možné využít validaˇcního serveru. Obecnˇe je jakákoli kontrola, u které si odborník dokáže pˇredstavit, že by ji naprogramoval, proveditelná validaˇcním serverem.

2.2 Vymezení cílu˚ 1. Navrhnout a realizovat webový systém pro odevzdávání souboru. ˚ Bude-li se jednat o zdrojový kód, tento systém soubor pˇrekontroluje pomocí externího validátoru dodaného Západoˇceskou univerzitou v Plzni. 2. Navrhnout a realizovat modul pro vyhledávání duplicitních zdrojových kódu. ˚ 3. Umožnit hromadný import uživatelu˚ podle pˇredem definovaného XML3 formátu. 4. Umožnit zobrazení studentu˚ registrovaných do systému podle jejich výsledku, ˚ studijních skupin a paralelky tak, aby nebyla porušena ochrana osobních údaju. ˚ 5. Umožnit odevzdání prací z více pˇredmˇetu˚ a tomu podˇrídit definici rolí jednotlivých uživatelu. ˚

1

XHTML (eXtensible HyperText Markup Language) - znaˇckovací jazyk urˇcený pro tvorbu hypertextových dokumentu. ˚ 2 W3C (World Wide Web Consortium) - mezinárodní konsorcium dohlížející na vývoj internetových standardu. ˚ 3 XML (eXtensible Markup Language) - jazyk umožnující ˇ popsat strukturu dokumentu z hlediska vˇecného obsahu jednotlivých cˇ ástí.

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ

3

3 Analýza a návrh rˇ ešení Tato kapitola popisuje technologie použité bˇehem návrhu a realizace systému. Dále se zabývá analýzou abstraktních problému˚ a cílu˚ práce a jejich pˇreformulování na konkrétní návrhy rˇešení. Další cˇ ást je zamˇerˇena na popis validátoru zdrojových kódu. ˚

3.1 Výbˇer implementaˇcního prostˇredí Hlavním kritériem pro výbˇer technologií uvedených v této cˇ ásti bylo splnˇení následujících požadavku: ˚ stabilita - stabilita a robustnost, uživatelská pˇrívˇetivost - snadná orientace v prostˇredí, pˇrenositelnost - platformní nezávislost a pˇrenositelnost, legálnost - k realizaci a provozu nebude použit žádný nelegální software. 3.1.1

Java Enterprise Edition

Java Enterprise Edition [1] (oznaˇcováno Java EE, dˇríve J2EE) je standardizovaná platforma urˇcená pro vývoj a provoz podnikových aplikací a informaˇcních systému. ˚ Serverové aplikace na ní postavené se vyznaˇcují pˇredevším platformní nezávislostí a pˇrenositelností, robustností, škálovatelností a vysokou bezpeˇcností. V základu se jedná o rozšíˇrení platformy Java Standard Edition [2] (Java SE) o podporu pro tvorbu webových aplikací, webových služeb a distribuovaných vícevrstvých aplikací a jejím cílem je poskytnout vývojáˇri infrastrukturu, která mu usnadní jejich vývoj. Souˇcástí platformy Java EE jsou specifikace pro: - vývoj webových aplikací - Java Servlets, Java Server Pages (JSP), - vývoj sdílené business logiky - Enterprise Java Beans (EJB), Spring, - pˇrístup k legacy systémum ˚ - Java Connector Architecture (JCA), Hibernate, - pˇrístup ke zprávovému middleware - Java Messaging Services (JMS), - podpora technologií Web Services. Dále v textu je odkazováno na podmnožinu Java EE, která je používána pˇredevším pro vývoj webových aplikací. Vícevrstvé aplikace v Java EE se obecnˇe skládají z tˇechto vrstev: - prezentaˇcní vrstva, - aplikaˇcní vrstva, - vrstva persistence dat.

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ 3.1.1.1

4

Prezentaˇcní vrstva

Prezentaˇcní vrstva se stará o transformaci dat smˇerem k uživateli a o zpˇrístupnˇení funkcionality aplikace. Nejˇcastˇeji se jedná o webovou aplikaci, o klasickou aplikaci s GUI1 nebo stále cˇ astˇeji i o mobilní aplikaci pro mobilní telefon nebo pro zaˇrízení PDA2 . Pro realizaci webové ˇ prezentaˇcní vrstvy slouží technologie JavaServlets [3] a JavaServer Pages[9]. Casto se používají 3 také ruzné ˚ webové aplikaˇcní rámce, obvykle založené na architektuˇre MVC [4]. 3.1.1.2

Aplikaˇcní vrstva

Aplikaˇcní vrstva zajišt’uje vlastní funkcionalitu programu. Muže ˚ být realizována ruzným ˚ zpu˚ ˇ sobem, v jednoduchých pˇrípadech staˇcí obyˇcejná knihovna tˇríd. Casto je však používán nˇejaký framework, zajišt’ující základní služby (perzistence, rˇízení transakcí, rˇízení pˇrístupu, vzdálený pˇrístup, dependency injection, apod.). Vˇetšina frameworku˚ nabízí tzv. deklarativní pˇrístup. Pˇríkladem je Spring [5] nebo standard Enterprise JavaBeans [6]. 3.1.1.3

Vrstva persistence dat

Vrstva persistence dat slouží k ukládání dat do nˇejakého perzistentního úložištˇe, nejˇcastˇeji do relaˇcní databáze. Pro komunikaci se používá obvykle JDBC4 , cˇ asto ve spojení s nˇejakým nástrojem typu ORM5 (Java Persistence API [7], Hibernate [8]). 3.1.2

JavaServer Pages

JavaServer Pages [9] (JSP) je technologie pro psaní dynamických XHTML stránek založená na jazyce Java. jedná se o textové soubory s pˇríponou .jsp, které jsou pˇri prvním požadavku na zobrazení automaticky pˇrevedeny servletovým kontejnerem na servlet (.java) a pˇreloženy do Java tˇrídy (.class). Servlety jsou speciální tˇrídy napsané v jazyce Java, které komunikují s webovým serverem a mohou jednoduše využívat dalších Java tˇríd. Po jakékoliv další zmˇenˇe .jsp souboru dojde pˇri následujícím požadavku znovu k pˇrevodu na servlet a rekompilaci. Následná vyvolání jsou již jen spuštˇením metody service() pˇreloženého servletu, a jsou velice rychlá, protože nedochází k opakované analýze JSP stránky. Metoda service() kontroluje typ požadavku (GET, POST, PUT, atd.) a vyvolá pˇríslušnou metodu doGet, doPost, doPut, atd. 3.1.2.1

Skriptovací znaˇcky

JSP byly pˇri svém vzniku funkˇcností velmi podobné napˇr. jazykum ˚ ASP6 [10] nebo PHP7 [11]. ˇ Cásti stránky, které se zobrazovaly beze zmˇeny se skládaly ze standardních HTML8 tagu. ˚ 1

GUI (Graphical User Interface) - druh komunikace s poˇcítaˇcem mající podobu interaktivních grafických prvku˚ PDA (Personal Digital Assistant) - malý kapesní poˇcítaˇc, ovládaný obvykle dotykovou obrazovkou a perem 3 MVC (Model View Controller) - softwarová architektura, která rozdˇeluje datový model aplikace, uživatelské rozhraní a rˇ ídicí logiku do tˇrí nezávislých komponent tak, že modifikace nˇekteré z nich má minimální vliv na ostatní 4 JDBC (Java DataBase Connectivity) - registrovaná ochranná známka spoleˇcnosti Sun Microsystems, Inc. Puvodní ˚ význam je API pro programovací jazyk Java, které definuje jednotné rozhraní pro pˇrístup k relaˇcním databázím. 5 ORM (Object-Relational Mapping)- programovací technika pro konverzi dat mezi relaˇcními databázemi a objektovˇe orientovanými programovacími jazyky. 6 ASP (Active Server Pages) - skriptovací platforma spoleˇcnosti Microsoft Corporation, primárnˇe urˇcená pro dynamické zpracování webových stránek na stranˇe serveru. 7 PHP (Hypertext Preprocessor) - multiplatformní skriptovací programovací jazyk, urˇcený pro tvorbu dynamických webových stránek. 8 HTML (HyperText Markup Language) - znaˇckovací jazyk urˇcený pro tvorbu hypertextových dokumentu. ˚ 2


5

A cˇ ásti stránky, které se dynamicky mˇenily byly oznaˇceny speciálními JSP znaˇckami, z nichž vˇetšina zaˇcínala <% a konˇcila %>. Tyto cˇ ásti programovacího jazyka uvnitˇr HTML se nazývají skriptlety. Tento pˇrístup je dnes zavržený, protože promíchání HTML kódu se skriptlety bylo velmi nepˇrehledné a samotné stránky se špatnˇe opravovaly a udržovaly. Nicménˇe kvuli ˚ zpˇetné kompatibilitˇe JSP dodnes skriptlety podporují a jejich vložení do stránky je umožnˇeno pomocí tˇrí základních znaˇcek: - Výraz ve tvaru <% výraz %>, který vytiskne rˇetˇezcový výraz cˇ i promˇennou pˇrímo do generované stránky. - Skriptlet ve tvaru <% kód %>, který vloží kód na pˇríslušné místo v metodˇe service() výsledného servletu. - Deklarace ve tvaru <%! kód %>, která vloží kód na urˇcité místo mimo metodu service() výsledného servletu, což se muže ˚ hodit napˇríklad k definici pomocné metody pro cˇ asto se opakující cˇ innosti. Pro více informací o servletech a JSP stránkách muže ˚ posloužit napˇr. [12]. 3.1.2.2

Knihovny znaˇcek

V dnešní dobˇe se pˇri psaní JSP stránek a generování dynamického obsahu používají speciální znaˇcky, které vypadají podobnˇe jako XML znaˇcky: <prefix:jméno atribut="hodnota"/>, kde prefix urˇcuje pˇríslušnost k urˇcité rodinˇe znaˇcek a jméno specifikuje konkrétní znaˇcku. Mimo základních znaˇcek, které definuje specifikace JSP: <jsp:include page="soubor" /> - zavolání RequestDispatcher.include(), <jsp:forward page="soubor" /> - zavolání RequestDispatcher.forward(), <jsp:useBean id="id" scope="page|request|session|application" class="package.class" /> - najde nebo vytvoˇrí instanci JavaBeanu v daném rozsahu platnosti, <jsp:getProperty name="bean" property="nˇ eco" /> - najde atribut bean a zavolá getNˇeco(), eco" /> <jsp:setProperty name="bean" property="nˇ - najde atribut bean a zavolá setNˇeco(), je možné použít znaˇcky z jiných rodin znaˇcek, jejichž použití je nutné deklarovat na zaˇcátku JSP stránky:


6

<%@page contentType="text/html" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="f" uri="http://java.sun.com/jsp/jstl/fmt" %> <%@ taglib prefix="moje" uri="http://www.nekde.cz/moje" %> Deklarace sváže zvolený prefix se zadaným URI9 , podle kterého se vyhledá knihovna znaˇcek. Implementace knihoven znaˇcek se pˇridávají obvykle jako JAR10 soubory do projektové složky /WEB-INF/lib/. Každá knihovna obsahuje tzv. Tag Library Descriptor (TLD) soubor popisující jaké znaˇcky obsahuje. 3.1.3

JavaServer Faces

JavaServer Faces [13] (JSF) je webový framework postavený na programovacím jazyce Java, urˇcený pro vývoj profesionálních webových aplikací. Duvodem ˚ pro vznik JSF bylo pˇredevším striktní oddˇelení definice uživatelského rozhraní od programování aplikaˇcní logiky. Designéˇri se tak mohou vˇenovat své práci a nezatˇežovat se spletitostmi programovacího jazyka a stejnˇe tak jsou programátoˇri zbaveni povinností konzultovat svuj ˚ kód s designéry. Uživatelské rozhraní je definováno pomocí speciálních XML znaˇcek podobných JSP znaˇckám (viz kap. 3.1.2.2 „Knihovny znaˇcek“), kterým jsou pˇredávána data ze standardních Java beanu. ˚ Takto je aplikace rozdˇelena na uživatelské rozhraní (GUI) a aplikaˇcní logiku (business logic). JavaServer Faces zahrnují množinu: - pˇreddefinovaných komponent (výpis textu, vstup textu, combo box, atd.) umožnujících ˇ uchování stavu, ˚ zachytávání událostí, validaci vstupu, ˚ konvertování hodnot, definování navigace stránek a dále pˇrináší podporu pro vícejazyˇcnost a pˇrístupnost, - standardních komponent, - dvˇe knihovny JSP znaˇcek pro zobrazení JSF rozhraní uvnitˇr JSP stránek, - model událostí rˇízený na stranˇe serveru, - automatickou správu stavu˚ jednotlivých komponent, - managed Beans, - sjednocený jazyk pro spoleˇcné použití JSP 2.0 a JSF 1.2. Uživatelské rozhraní je modelováno pomocí komponent, což pˇrináší objektovˇe orientovaný pˇrístup do webového programování. Samozˇrejmostí je možnost rozšíˇrení standardní množiny komponent o své vlastní nebo o knihovny komponent tˇretích stran. Je tak možné do stránky umístit napˇríklad komponentu kalendáˇr a odpadá nutnost psát celý kód ruˇcnˇe. Další neménˇe významnou výhodou tohoto modelu je možnost testovat každou komponentu nezávisle, jako samostatný program. 3.1.3.1

Životní cyklus JSF

Celý proces od odeslání dotazu od uživatele prohlížeˇcem až po pˇrijetí odpovˇedi od serveru probíhá v nˇekolika fázích (obr. 3.1): 9

URI (Uniform Resource Identifier) - rˇ etˇezec znaku˚ s definovanou strukturou, který slouží k pˇresné specifikaci zdroje informací, hlavnˇe za úˇcelem jejich použití pomocí poˇcítaˇcové sítˇe. 10 JAR (Java Archive) - platformˇe nezávislý formát pro archivaci souboru. ˚


7

HTTP Request Vyvolání požadavku na klientské stranˇe, napˇr. stisknutí tlaˇcítka. Restore View Obnovení pˇredchozího stavu aplikace pro danou session, tj. vytvoˇrení komponentového stromu, který reprezentuje uživatelské rozhraní na stranˇe klienta. Pokud je session prázdná a není co obnovit (napˇr. pˇri prvním zobrazení stránky), pˇrejde se rovnou na fázi Render Response. Apply Request Values Zaslání stavu˚ komponent (napˇr. vyplnˇeného formuláˇre) na server a volání action metod navázaných na jednotlivé komponenty. Zárovenˇ je dekódován HTTP Request a z jeho položek nastaveny hodnoty komponent. Process Validations Spuštˇení registrovaných validátoru˚ na testování vstupních dat pro jednotlivé komponenty. Pˇri selhání validace se zaznamenají chybová hlášení od každé komponenty a prostˇredí na stranˇe klienta je znovu vykresleno, i s chybovými zprávami. Update Model Values Po úspˇešné validaci jsou na stranˇe serveru v Java Beanech pomocí setteru˚ nastaveny hodnoty, které jsou navázány na jednotlivé komponenty. Invoke Application Spuštˇení action metody, navázané na komponentu, která vyvolala HTTP Request. V metodˇe muže ˚ být definován klíˇc pro pˇresmˇerování na další stránku. Render Response Zapsání dat do výstupního proudu HTTP Response, tj. vygenerování serverové odpovˇedi pro klienta. HTTP Response Zobrazení HTTP Response na stranˇe klienta.

Obrázek 3.1: Životní cyklus zpracování událostí v JSF. (zdroj [14]) JSF aplikace tedy bˇeží na stranˇe serveru, kde je zabalena do standardního servletového kontejneru (napˇr. Tomcat) a s klientskou cˇ ástí komunikuje pˇres HTTP pˇríkazy. Kontejnerem pro JSF komponenty jsou nejˇcastˇeji JSP stránky a každá taková stránka je reprezentována komponentovým stromem. 3.1.3.2

Navigace v JSF

V kapitole 3.1.3.1 „Životní cyklus JSF“ je ve fázi Invoke Application uvedeno, že pro pˇresmˇerování na jinou stránku je nutné mít definovaný klíˇc. Tento klíˇc je rˇetˇezec typu String a jeho popis se definuje v tzv. navigaˇcním pravidle. Všechna navigaˇcní pravidla jsou umístˇena v XML souboru faces-config.xml, který je uložen v projektovém adresáˇri WEB-INF. Definice dvou navigaˇcních pravidel muže ˚ vypadat napˇr. takto:


8

1 2 ... 3 4 index.jsp 5 6 singin 7 userHome.jsp 8 9 10 11 12 settings 13 su/settings.jsp 14 15 ... 16 Každé navigaˇcní pravidlo (navigation-rule) urˇcuje, jak se dostat z jedné stránky (from-tree-id) na jiné. Navigation-rule element obsahuje libovolný poˇcet navigation-case elementu, ˚ které definují, na kterou stránku má být po zavolání klíˇce (from-outcome) smˇerováno (to-tree-id). První pravidlo pˇresnˇe definuje možnost zavolání klíˇce singin jen ze stránky index.jsp a pˇresmˇerování povede na stránku userHome.jsp. Druhé pravidlo je více benevolentnˇejší a povoluje zavolání klíˇce settings z jakékoli stránky a vždy povede pˇresmˇerování na stránku su/settings.jsp. Tento zpusob ˚ definice navigaˇcního pravidla se muže ˚ hodit napˇr. pˇri tvorbˇe položek v menu aplikace, které bývá umístˇeno na všech stránkách. Action metoda navázaná na komponentu, ve které muže ˚ vracet klíˇc pro pˇresmˇerování na jinou stránku je definována v tzv. JavaBeanˇe. 3.1.4

Java Beans

Java Beans [15] jsou tˇrídy napsané v jazyce Java, které slouží ke konfiguraci aplikaˇcní logiky a k uchování hodnot komponent pro webové aplikace. K promˇenným instance tˇrídy JavaBeans se pˇristupuje pouze prostˇrednictvím tzv. setteru˚ a getteru, ˚ které umožnují ˇ nastavit a pˇreˇcíst jednotlivé hodnoty. Níže uvedený pˇríklad beany obsahuje metody setter a getter pro pˇrístup k promˇenné hodnota a navíc metodu singinButton_action, která vrací navigaˇcní klíˇc singin pro pˇresmˇerování definované v kapitole 3.1.3.2 „Navigace v JSF“. 1 public class IndexBean { 2 3 private String hodnota; 4 5 public String getHodnota() { 6 return hodnota; 7 } 8 9 public void setHodnota(String honota) { 10 this.hodnota = hodnota; 11 } 12

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ 13 14 15 16 }

public String singinButton_action() { return "singin"; }

3.1.4.1

Java Beans a JSF

9

Na úrovni JavaBeans není nutné vˇedˇet jakým zpusobem ˚ se daná informace uživateli zobrazí nebo jakým zpusobem ˚ se od uživatele získá. Duležitá ˚ je jen konfigurace mapování beany na danou JSF stránku. Každou vytvoˇrenou beanu je nutné pro aplikaci zaregistrovat. Registrace se provádí v XML souboru faces-config.xml, který je umístˇen v projektovém adresáˇri WEB-INF. Jeho obsah muže ˚ vypadat napˇr. takto: 1 2 ... 3 <managed-bean> 4 <description>popis beany 5 <managed-bean-name>index 6 <managed-bean-class> 7 odevzdavacisystem.IndexBean 8 9 <managed-bean-scope>request 10 11 ... 12 Uvnitˇr elementu description je uveden popis beany. Uvnitˇr managed-bean-class je uveden název, pˇres který se na beanu odkazuje z JSF souboru. Element managed-bean-class definuje fyzickou cestu k beanˇe. A element managed-bean-scope definuje, zda je beana uchovávána v rámci session nebo jen pro request požadavek. Po zaregistrování staˇcí do pˇríslušné stránky pˇridat JSF komponenty a namapovat jejich hodnoty na vytvoˇrenou beanu. Na pˇríkladu níže je hodnota zadaná do vstupního pole (h:inputText) uložena do beany do promˇenné hodnota. Atribut required znaˇcí nutnost vyplnit vstupní pole textem. Pokud by pole zustalo ˚ prázdné a uživatel by stiskl tlaˇcítko pro pˇrihlášení (h:commandButton), zobrazila by se výstupní hláška (h:message) o chybˇející hodnotˇe. V opaˇcném pˇrípadˇe, když by vstupní pole uživatel vyplnil, došlo by po stisknutí tlaˇcítka k zavolání metody singinButton_action, která by podle definice uvedené výše provedla pˇresmˇerování na stránku userHome.jsp. 1 2 4 5 7 V kapitole 3.1.3.1 „Životní cyklus JSF“ je zmínˇeno, že aplikace komunikuje s klientskou cˇ ástí jen pomocí HTTP pˇríkazu. ˚ Z toho vyplývá, že s JavaBeany se pracuje jen na stranˇe serveru a odpadá nutnost mít na klientské stanici nainstalovaný Java Runtime Environment. Pro více informací o technologii JavaServer Faces muže ˚ posloužit napˇr. [16].

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ 3.1.5

10

ICEfaces

ICEfaces [17] je ajaxový framework rozšiˇrující aplikace postavené na platformˇe Java EE o Ajax11 [18] technologii. Umožnuje ˇ vytvoˇrení tzv. Rich Internet Application12 [19] s použitím cˇ istého programovacího jazyka Java, bez JavaScriptu [20]. Prezentaˇcní vrstva ICEfaces je postavena pˇredevším na JavaSever Faces standardech. Stejnˇe jako v JSF je uživatelské rozhraní definováno pomocí speciálních XML znaˇcek, které umožnují ˇ propojení se standardními Java beanami. V základu ICEfaces obsahuje pˇres 50 pˇripravených JSF ajaxových komponent (napˇr. kalendáˇr, vstupní pole podobné textovým editorum ˚ apod.) a velké množství dodateˇcných efektu˚ a animací. 3.1.5.1

ICEfaces architektura

Primárním cílem ICEfaces architektury je striktní oddˇelení cˇ isté Javy od nízkoúrovnového ˇ JavaScriptu. Programátor pracuje jen s programovacím jazykem Java a to i pˇresto, že veškerá komunikace mezi serverovou a klientskou cˇ ástí je uskuteˇcnována ˇ jen pomocí technologie Ajax. Architektura ICEfaces se skládá ze tˇrí hlavních cˇ ástí (obr. 3.2):

Obrázek 3.2: ICEfaces architektura. (zdroj [17]) ICEfaces Framework ICEfaces framework je rozšíˇrení standardního JSF frameworku o vykreslovací fázi. Standardní JSF aplikace po každém vyvolání požadavku na stranˇe klienta na serveru obnoví stavy všech komponent, zašle je prohlížeˇci a ten celou stránku aktualizuje (viz kap. 3.1.3.1 „Životní cyklus JSF“). ICEfaces framework si na serveru uchovává vlastní komponentový strom složený z ICEfaces komponent (Server DOM), který je identický se stromem komponent na stranˇe klienta (DOM). Pˇri vyvolání klientského požadavku a následné zmˇenˇe stromu na stranˇe serveru je provedena aktualizace (Incremental DOM Updates) klientského stromu a to jen tˇech komponent, které to vyžadují. Komunikace mezi serverem a klientem v této fázi probíhá pˇres tzv. Ajax Bridge. Ajax Bridge Ajax Bridge je pˇremostˇení mezi klientským prohlížeˇcem a serverem a koordinuje komunikaci mezi nimi. Tento most je zodpovˇedný za doruˇcení aktualizaˇcních požadavku˚ (Incremental 11

AJAX (Asynchronous Javascript And XML) - technologie umožnující ˇ interaktivní zmˇenu cˇ ástí webové stránky bez nutnosti znovunaˇctení celé stránky. 12 RIA (Rich Internet Application) - smˇer, který se snaží pˇreklenout rozdíly mezi klasickou webovou a desktopovou aplikací.


11

DOM Updates) od serveru k prohlížeˇci a podle nich pˇrestavuje klientský strom komponent. Zárovenˇ detekuje události, které uživatel v prohlížeˇci uskuteˇcní a zasílá je zpˇet na server (DOM Partial Submit) na poˇcátek životního cyklu pˇríslušných komponent (viz kap. 3.1.3.1 „Životní cyklus JSF“). Podle výstupu životního cyklu je upraven JSF komponentový strom aplikace, který je následnˇe transformován na ICEfaces serverový komponentový strom. ICEfaces Components ICEfaces komponenty mají všechny vlastnosti pro tvorbu uživatelského rozhraní. Jedná se o rozšíˇrení standardních JSF komponent a pˇridání množiny nových vyspˇelejších komponent, které umožnují ˇ vytvoˇrit efektivnˇejší webovou aplikaci. Všechny komponenty jsou uzpu˚ sobeny pro ajaxovou komunikaci skrz Ajax Bridge a mohou tak být jednotlivˇe bez ovlivnování ˇ jiných komponent aktualizovány, validovány nebo mohou využít automatického doplnování ˇ textu. 3.1.6

Hibernate

Hibernate [8] je komplexní nástroj pro perzistenci dat, tj. mapování tˇríd jazyka Java na tabulky relaˇcní databáze. Objekty které se takto mapují se nazývají Entity a je možné s nimi jakkoli manipulovat, pˇrípadnˇe se na nˇe databázovˇe dotazovat pomocí jazyka Hibernate Query Language (HQL). Další mechanismy, které Hibernate poskytuje, umožnují ˇ transakˇcní zpracování, polymorfní perzistenci, kešování, vlastní datové typy a mnoho dalších. 3.1.6.1

Java Persistence API

Java Persistence API [7] (JPA) je specifikace standardizující objektovˇe-relaˇcní mapování. Jedním z principu˚ této specifikace je umožnit zmˇenu perzistentního nástroje za jiný, bez jakéhokoli vlivu na funkˇcnost aplikace. To s sebou pˇrináší mnohé výhody, kdy napˇr. pˇri ukonˇcení vývoje jednoho nástroje je možné jednoduše pˇrejít na jiný. Aby taková zmˇena byla možná, musejí mít všechny perzistentní nástroje pˇrizpusobenou ˚ množinu svých vlastností pro JPA. Vˇetšina ale obsahuje mnohem více funkcí, které se pro každý nástroj liší a ty už nemohou být ve standardu využity. Hibernate je standardu JPA pˇrizpusoben ˚ od verze 3.2. 3.1.6.2

Anotace

Vlastní mapování objektu˚ na tabulky se ve standardu JPA zapisuje pomocí tzv. anotací, což jsou meta-informace uvedené pˇrímo v java kódu dané entity. Anotace se zapisují bud’ pˇred atribut tˇrídy (getter ani setter nemusí být definovány) nebo k getteru entitního atributu. Vždy jde použít bud’ jeden nebo druhý zpusob, ˚ ne kombinovanˇe. Kompletní seznam anotací a všech jejich atributu˚ je uveden v balíˇcku javax.persistence na [23]. Níže uvedený seznam obsahuje nejpoužívanˇejší anotace: @Entity - oznaˇcení tˇrídy, která bude pˇrevedena na entitu. @Id - oznaˇcení primárního klíˇce @Column - definuje detaily sloupce @OneToOne - definuje vztah 1:1 @OneToMany - definuje vztah 1:N @ManyToOne - definuje vztah N:1 @ManyToMany - definuje vztah M:N @Transient - oznaˇcuje atribut, který nebude mapován @Lob - oznaˇcuje atribut, který bude použit jako BLOB/CBLOB

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ 3.1.6.3

12

Entity Manager a práce s objekty

Entity Manager je základní objekt, pro práci s JPA. Stará se o jednotlivé objekty, spravuje jejich životní cyklus, pˇrekládá volání metod na SQL pˇríkazy, udržuje spojení s databází atd. Pˇred první komunikací s databází je nutné vytvoˇrit tzv. Entity Manager Factory (ˇrádek 3), který spravuje jednotlivé Entity Managery. Z nˇeho se pˇred každou databázovou operací vytvoˇrí Entity Manager (ˇrádek 7), který se po dané operaci zavˇre (ˇrádek 12). Napˇr. takto: 1 2 3 4 5 6 7 8 9 10 11 12 13

// vytvoˇ rení Entity manager factory // (jednou pro celé sezení) EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("odevsys"); // vytvoˇ rení správce entit EntityManager entityManager = entityManagerFactory.createEntityManager(); try { // použití správce entit na objekty } finally { rení správce entit // uzavˇ entityManager.close(); }

Pomocí vytvoˇreného Entity Manageru lze bˇežnˇe manipulovat s daty databáze, napˇr. takto: - naˇctení jednoho urˇcitého objektu podle jeho id (viz pˇr. 1), - naˇctení všech objektu˚ urˇcitého typu (viz pˇr. 2), - naˇctení jednoho urˇcitého objektu podle jeho atributu (viz pˇr. 3), - uložení objektu do databáze (viz pˇr. 4), - odstranˇení objektu z databáze (viz pˇr. 5), - použití transakˇcního zpracování. Vrátí-li nˇekterý z pˇríkazu˚ uvnitˇr transakce chybu, zruší se celá transakce (viz pˇr. 6). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// pˇ r. 1: naˇ ctení jednoho pˇ redmˇ etu Subject subject = (Subject) entityManager.find( Subject.class, subjectId); // pˇ r. 2: naˇ ctení všech pˇ redmˇ et˚ u Query query = entityManager.createQuery("select object(s) " + " from Subject as s"); List<Subject> subjectList = query.getResultList(); etu redmˇ citého pˇ ctení jednoho urˇ r. 3: naˇ // pˇ Query query = entityManager.createQuery("select object(s) from Subject " + " as s where s.code = ?"); query.setParameter(0, "Y36ALG"); Subject subject = (Subject) query.getSingleResult();

ˇ KAPITOLA 3. ANALÝZA A NÁVRH REŠENÍ 17 18 19 20 21 22 23 24 25 26

13

// pˇ r. 4: uložení objektu do databáze entityManager.persist(subject); // pˇ r. 5: odstranˇ ení objektu z databáze entityManager.remove(subject); // pˇ r. 6: transakˇ cní zpracování entityManager.getTransaction().begin(); // pˇ ríkazy uvnitˇ r transakce entityManager.getTransaction().commit();

3.1.6.4

Životní cyklus entity

Každá entita se nachází v jednom ze 4 stavu, ˚ který se mˇení voláním pˇríslušných metod pˇres Entity Manager 3.3: new/transient (nový nebo uložený) - instance, která je mimo správu JPA. Napˇr. novˇe vytvorˇená instance, která nebyla uložena metodou persist(). managed (spravovaný) - objekt pod správou JPA. Jedná se objekt, na který byla zavolána metoda persist(). detached (odpojený) - objekt odpojen od Entity Manageru po jeho uzavˇrení. removed (odstranˇený) - objekt, který ještˇe existuje v podobˇe instance, ale z databáze je už odstranˇený metodou remove().

Obrázek 3.3: Životní cyklus entity. New/transient - objekt mimo správu JPA, managed - objekt pod správou JPA, detached - uzavˇrení Entity Manageru, removed - objekt odstranˇen. (zdroj [21])


14

3.2 Modul vyhledávání duplicitních prací 3.2.1

Popis modulu

Stále cˇ astˇeji se vyskytují pˇrípady, kdy jeden student vypracuje úlohu, ostatní ji od nˇej zkopírují, pˇrípadnˇe upraví cˇ ást kódu a podobné rˇešení sami odevzdají. Nejen, že se v takovém pˇrípadˇe jedná o opisování, ale studenti se zárovenˇ pˇripravují o možnost rozšíˇrit si své znalosti a vˇedomosti pˇri rˇešení problému, který úloha zadává. Modul pro vyhledávání duplicitních prací se snaží všechny podobné odevzdané práce najít a seˇradit je podle podobnosti. 3.2.2

Princip funkce

V poˇcátcích vývoje byl systém primárnˇe urˇcen pro podporu výuky pˇredmˇetu˚ Algoritmizace a Programování v jazyku Java, které jsou vyuˇcovány Katedrou poˇcítaˇcu˚ na Fakultˇe elekˇ trotechnické Ceského vysokého uˇcení technického v Praze. V tˇechto pˇredmˇetech studenti odevzdávají vˇetšinou jednoduché úlohy, napsané v programovacím jazyku Java. Proto je vyhledávání pˇrizpusobeno ˚ na jednoduché zdrojové kódy a dukladnost ˚ rozdˇelena do tˇrech základních úrovní: 1. úrovenˇ - kontrola znak po znaku 2. úrovenˇ - vymazání všech komentáˇru, ˚ bílých znaku, ˚ názvu tˇríd a metod, package a import a následná kontrola znak po znaku 3. úrovenˇ - 2. úrovenˇ + odstranˇení názvu identifikátoru˚ a porovnání poˇradí klíˇcových slov První úrovenˇ je urˇcena pro vyhledání prací, které jsou naprosto stejné a podvodníky nijak neupravené. Druhá úrovenˇ se zamˇerˇuje pˇredevším na práce, ve kterých byly pozmˇenˇeny komentáˇre, názvy tˇríd, metod, název package, pˇrípadnˇe byly pˇridány mezery nebo zmˇenˇeno rˇádkování. Tˇretí úrovenˇ je identická s druhou úrovní, ale navíc dokáže najít i práce, ve kterých byly pozmˇenˇeny názvy identifikátoru, ˚ pˇrípadnˇe byly pˇrehozeny nˇekteré podobné rˇádky. Pˇri porovnávání dvou prací na tˇretí úrovni je možné najít napˇr. takto pozmˇenˇenou práci: // p˚ uvodní práce int a = 1; int b = 2; // opsaná práce int b = 2; int a = 1; Za klíˇcová slova jsou na této úrovni považována: abstract, boolean, break, byte, case, catch, char, class, continue, do, double, else, false, final, finally, float, for, if, implements, import, instanceof, int, interface, long, native, new, null, package, private, protected, public, return, short, static, super, switch, synchronized, this, throw, throws, transient, true, try, void, volatile a while. Poˇradí klíˇcových slov je pro každé z porovnávaných prací zaznamenáno a následnˇe porovnáno. Pokud je poˇradí všech klíˇcových slov stejné, úloha je oznaˇcena jako opis. Tato pravidla jsou zamˇerˇena pˇredevším na jednoduché úlohy, ale není žádný problém modul o další dukladnˇ ˚ ejší úrovnˇe vyhledávání rozšíˇrit.


15

3.3 Modul importování uživatelu˚ 3.3.1

Popis modulu

Jak bylo zmínˇeno v kapitole 1.1 „Duvody ˚ vzniku systému“, systém je navržen pˇredevším pro školy a vzdˇelávací instituce, kde se pˇredpokládá velké množství uživatelu. ˚ Systém musí být schopen registrace jednotlivých uživatelu, ˚ ale samozˇrejmostí musí být i registrace tˇreba stovky uživatelu˚ v jednom kroku. 3.3.2

Uživatelské role

S každou úlohou, která má být v systému zadána, pracuje nˇekolik typu˚ uživatelu. ˚ Jeden muže ˚ vytvoˇrit pˇredmˇet, ve kterém se bude úloha odevzdávat. Jiný úlohu vytvoˇrí a zadá ji do systému. A další se bude snažit úlohu vypracovat a odevzdat. Každý takový uživatel musí mít pˇresnˇe stanovené oprávnˇení, co muže ˚ a co nemuže ˚ dˇelat. Aby systém rozpoznal, který uživatel muže ˚ napˇríklad zadávat úlohu a který ji muže ˚ odevzdávat, má každý uživatel definovanou tzv. „Uživatelskou roli“. Odevzdávací systém rozlišuje 4 uživatelské role s rozdílnými privilegii. 3.3.2.1

Role Student

Student má možnost pˇrihlásit se do systému pod svým uživatelským jménem, heslem a pˇredmˇetem, do kterého je zaregistrován. Každý student vidí všechny úlohy, které byly vytvoˇreny pro jeho pˇredmˇet, pˇrípadnˇe pro jeho cviˇcící skupinu a muže ˚ je odevzdat. Dále má možnost prohlížet všechny svoje odevzdané úlohy a výsledky jejich validace. Student muže ˚ mˇenit své kontaktní údaje. 3.3.2.2

Role Uˇcitel

Uˇcitel má stejnˇe jako student možnost pˇrihlásit se do systému pod svým uživatelským jménem, heslem a pˇredmˇetem, do kterého je zaregistrován. Muže ˚ vytváˇret nové množiny úloh pro studenty ze svých cviˇcících skupin. Úlohy muže ˚ pro otestování sám odevzdat a prohlédnout si výsledky validace. Dále má možnost prohlédnou si odevzdané práce a výsledky validace všech studentu˚ ze svých cviˇcících skupin (vˇcetnˇe svých). Uˇcitel muže ˚ také pˇridávat nové uživatele s rolí student a mˇenit osobní údaje všech uživatelu˚ z jeho cviˇcících skupin. Dále muže ˚ mˇenit parametry vytvoˇrených množin úloh. 3.3.2.3

Role Administrátor

Administrátor se muže ˚ pˇrihlásit se do systému pod svým uživatelským jménem, heslem a pˇredmˇetem, do kterého je zaregistrován. Muže ˚ vytváˇret nové množiny úloh pro všechny studenty ve vybraném pˇredmˇetu. Úlohy muže ˚ pro otestování sám odevzdat a prohlédnout si výsledky validace. Dále má možnost prohlédnou si odevzdané práce a výsledky validace všech studentu˚ z vybraného pˇredmˇetu. Administrátor muže ˚ také pˇridávat nové uživatele s rolemi student a uˇcitel a mˇenit osobní údaje všech uživatelu˚ z jeho cviˇcících skupin (vˇcetnˇe svých). Dále muže ˚ mˇenit parametry vytvoˇrených množin úloh. 3.3.2.4

Role Super uživatel

Super uživatel má stejná oprávnˇení jako Administrátor, ale nemusí se do systému pˇrihlašovat pod žádným pˇredmˇetem, respektive se muže ˚ pˇrihlásit pod jakýmkoli pˇredmˇetem. Navíc má možnost vytvoˇrit nový pˇredmˇet a novou cviˇcící skupinu a zaregistrovat do nich nové


16

uživatele s rolemi student, uˇcitel, administrátor a super uživatel a mˇenit osobní údaje všech uživatelu˚ v systému (vˇcetnˇe svých). Dále muže ˚ mˇenit parametry všech pˇredmˇetu, ˚ množin úloh a cviˇcících skupin. Super uživatel muže ˚ nastavit cestu k externímu validátoru, který se bude používat pro validaci zdrojových kódu. ˚ 3.3.3

XML šablona

Uživatelé systému s rolí uˇcitel, administrátor nebo super administrátor mohou do systému pˇridávat nové uživatele. Aby nemuseli každého uživatele pˇridávat zvlášt’, zahrnuje systém vlastnost pro hromadný import uživatelu˚ z pˇredem definovaného XML souboru. Extensible Markup Language (XML) je obecný znaˇckovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Umožnuje ˇ snadné vytváˇrení konkrétních znaˇckovacích jazyku˚ urˇcených napˇr. pro výmˇenu dat mezi aplikacemi. Jazyk umožnuje ˇ popsat strukturu dokumentu z hlediska vˇecného obsahu jednotlivých cˇ ástí. Pro import uživatelu˚ do Odevzdávacího systému byl pomocí XML vytvoˇren znaˇckovací jazyk s níže uvedenými párovými znaˇckami. Znaˇcky, které jsou nezbytné pro správný import jsou oznaˇceny slovem „povinné“. import - uvnitˇr jsou jednotliví uživatelé, každý oznaˇcen znaˇckou user (povinné) user - uvnitˇr jsou atributy jednoho uživatele (povinné) nickname - pˇrihlašovací jméno (povinné) password - pˇrihlašovací heslo right - uživatelská role (user, teacher, admin) (povinné) firstname - jméno (povinné) lastname - pˇríjmení (povinné) email - email (povinné) locale - preferovaný jazyk systému (cs, en) subjects - uvnitˇr jsou jednotlivé pˇredmˇety, každý oznaˇcen znaˇckou subject subject - kód pˇredmˇetu (povinné) classes - uvnitˇr jsou jednotlivé tˇrídy, každá oznaˇcena znaˇckou class (povinné jen pokud znaˇcka right obsahuje atribut user nebo teacher) class - uvnitˇr jsou atributy jedné tˇrídy (povinné, je-li uvedena znaˇcka classes) number - cˇ íslo cviˇcící skupiny (povinné, je-li uvedena znaˇcka classes) group - cˇ íslo paralelky (povinné, je-li uvedena znaˇcka classes) Není-li vyplnˇena znaˇcka password, bude v pˇrípadˇe použití systému pro Fakultu elektrotechˇ nickou Ceského vysokého uˇcení technického v Praze použit pro autentizaci uživatelu˚ interní ovˇerˇovací systém. Pomocí XML souboru nelze z duvodu ˚ bezpeˇcnosti importovat uživatele typu Super uživatel. Pˇri nevyplnˇení znaˇcky locale je uživateli nastaven výchozí jazyk cˇ eština. Níže je uveden fragment XML souboru, který po naˇctení do systému vytvoˇrí nového uživatele Karla Vomáˇcku.


17

1 2 3 ... 4 <user> 5 vomacka 6 <password>heslo 7 teacher 8 Karel 9 Vomáˇ cka 10 <email>[email protected] 11 cs 12 <subjects> 13 <subject>Y36PJV 14 15 16 17 101 18 1 19 20 21 102 22 1 23 24 25 26 ... 27

3.4 Validátor zdrojových kódu˚ Validátor zdrojových kódu˚ použitý v Odevzdávacím systému byl dodán Katedrou informatiky a výpoˇcetní techniky Západoˇceské univerzity v Plzni. Nˇekteré cˇ ásti textu v této kapitole se opírají o dokumentaci dodanou spoleˇcnˇe s validátorem [25]. 3.4.1

Popis validátoru

Každá vypracovaná úloha je ihned po odevzdání v systému archivována. Pokud uživatel odevzdal úlohu programovacího charakteru, tedy napˇr. zdrojový kód napsaný v programovacímu jazyku Java, musí být práce urˇcitým zpusobem ˚ pˇrekontrolována a uživateli sdˇelen výsledek kontroly. Kontrola zdrojového kódu probíhá za pomocí tzv. validátoru. Validátor je samostatná aplikace, bˇežící mimo Odevzdávací systém. Vzdálené spojení je zprostˇredkováno pomocí RMI13 a bˇehem nˇeho je validátoru zaslán zdrojový kód. Ten je ihned po pˇrijmutí pˇreložen a pokud je vše korektní, je z kódu novˇe vzniklá aplikace pomocí validátoru spuštˇena. Pˇri každém požadavku o vstupní data, jsou postupnˇe vkládány kontrolní hodnoty, které byly vytvoˇreny zadavatelem úlohy. Po skonˇcení aplikace jsou pˇreˇctena její výstupní data (oznaˇcena speciálním rˇetˇezcem, aby se nemohla splést s jinými daty) a jsou pˇrekontrolována s výstupními daty vzorové úlohy. Vzorová úloha je program vytvoˇrený zadavatelem úlohy, který slouží jako etalon bˇehem validace. Jsou-li data stejná, úloha je ozna13 RMI (Remote Method Invocation) - rozhraní umožnující ˇ objektu z jednoho virtuálního stroje (JVM) volat metody jiného objektu z jiného virtuálního stroje


18

cˇ ena jako úspˇešnˇe zvalidovaná. V opaˇcném pˇrípadˇe je úloha oznaˇcena jako neúspˇešná a uživateli je vrácena zpráva s výpisem chyb. 3.4.2

Princip funkce validátoru

Následující diagram pˇredstavuje proces, jakým práce prochází po studentovˇe odevzdání. Jedná se o odevzdání zdrojového kódu, kdy je využito i validátoru.

Obrázek 3.4: Proces validace zdrojového kódu. (zdroj [25])

1. Odevzdání práce studentem Student si v nabídce odevzdávacího systému vybere zapsaný pˇredmˇet a pod svým uživatelským jménem a heslem se pˇrihlásí. Pomocí jednoduchého formuláˇre v systému projde svuj ˚ pevný disk a vybere soubor k odevzdání. Systém zjistí, že se jedná o zdrojový kód a soubor pˇrepošle validaˇcními serveru. 2. Pˇríjem souboru validaˇcním serverem Soubor je uložen na pevném disku validaˇcního serveru. 3. Urˇcení validaˇcní domény Validaˇcní doména definuje konkrétní pravidla a proces, jakým bude validace probíhat. Každá skupina úloh, jejichž kontrola se provádí stejným zpusobem ˚ má jednu validaˇcní doménu.


19

4. Úvodní kontroly Odevzdaný soubor projde prvními triviálními kontrolami na základˇe definic dané domény - maximální velikost, možné pˇrípony apod. Splnuje-li ˇ soubor tyto základní formální požadavky, postupuje dál. 5. Pˇríprava na validaci V tomto bodˇe zaˇcne server pˇripravovat podmínky pro spuštˇení vlastních validaˇcních skriptu: ˚ a) Vytvoˇrení vlákna pro validaci, omezení doby validace na zadané maximum Každá validace probíhá v samostatném vláknˇe, pˇriˇcemž je možno omezovat maximální dobu trvání validace (i jednotlivých jejích cˇ ástí). b) Vytvoˇrení pracovního adresáˇre pro tuto validaci Vytvoˇrí se nový adresáˇr s jedineˇcným názvem a do nˇej se soubor nahraje. c) Uložení kopie souboru Pro pˇrípad pozdˇejšího dohledání se každý zaslaný soubor ukládá do adresáˇre k tomu urˇcenému. d) Vytvoˇrení potˇrebných promˇenných, které jsou pozdˇeji k dispozici skriptu Generování vstupních dat pro kontrolu programu. 6. Spuštˇení vlastního validaˇcního procesu Je spuštˇen validaˇcní proces, který je definován pro konkrétní validaˇcní doménu. Jedná se o kontroly XML elementu˚ pomocí skriptového programu. Script muže ˚ využívat mnoho služeb poskytovaných validaˇcním serverem a bˇehem kontroly zaznamenává ruzné ˚ informace, varování, chyby a postupnˇe tak generuje výsledek validace. 7. Zpracování výsledku˚ Bˇehem validace se postupnˇe vytváˇrí výsledek validace. Ten obsahuje nejruznˇ ˚ ejší informace o validaci, chybové hlášky a vlastnˇe cokoli, co autor validace považuje za duležité ˚ sdˇelit studentum, ˚ kteˇrí práci odevzdali. Tento výstup muže ˚ být pˇreveden do formy hypertextového dokumentu a umístˇen do datového úložištˇe k okamžitému pˇrístupu pˇres web. Možné jsou další formy výstupu, napˇríklad uložení do databáze cˇ i XML souboru. ˇ ení 8. Cištˇ Odstranˇení pomocných souboru˚ a adresáˇru, ˚ které vznikly bˇehem validace a dále nejsou potˇreba. 3.4.3

Konfigurace validaˇcního serveru

Konfiguraˇcní soubor validátoru server.xml je uložen v koˇrenovém adresáˇri validátoru. Jedná se o soubor ve formátu pro Java-Properties, který je naˇcítán vždy bˇehem spuštˇení validaˇcního serveru. Jakákoli zmˇena v nastavení nabude platnosti až po jeho restartování. Níže uvedený fragment souboru server.xml popisuje nejduležitˇ ˚ ejší nastavení: 1 <properties version="1.0"> 2 ... 3 <entry key="rmi.port">1097 4 <entry key="core.java_path">/usr/bin/java 5 <entry key="core.domains_dir">domains


20

6 <entry key="domain.enabled">javaSource 7 <entry key="domain.properties_file">domain.xml 8 <entry key="domain.process_file">process.xml 9 <entry key="output.results_starter">---Vysledky--- 10 ... 11 Popis atributu: ˚ rmi.port RMI port, na kterém bude validátor dostupný pro vzdálené zasílání dat. core.java_path Cesta k pˇríkazu "java", který je používán pro spouštˇení pˇreložených Java souboru. ˚ core.domains_dir Relativní cesta k adresáˇri s validaˇcními doménami. domain.enabled Seznam aktivních domén, oddˇelených cˇ árkou. Názvy musejí souhlasit s názvy adresáˇru˚ ve výše nastaveném adresáˇri s validaˇcními doménami. domain.properties_file Název souboru s nastavením domény. domain.process_file Název souboru s definicí procesu validace pro doménu. ˇ ezec, který ve výstupu spuštˇeného programu oznaˇcuje data urˇcená output.results_starter Retˇ ke kontrole. Detailní seznam a význam všech nastavení je uveden v pˇriložené dokumentaci [25]. 3.4.4

Konfigurace domény

Konfiguraˇcní soubory domény domain.xml a process.xml (název souboru˚ je závislý na nastavení atributu˚ domain.properties_file a domain.process_file v konfiguraˇcním souboru validátoru) jsou umístˇeny ve složce pˇríslušné domény. Jedná se o soubory ve formátu pro Java-Properties, jejich nastavení se naˇcítají po spuštˇení validaˇcního serveru. Jakékoli zmˇeny nabudou platnost až po jeho restartování. Níže uvedený fragment souboru domain.xml popisuje nejduležitˇ ˚ ejší nastavení: 1 <properties version="1.0"> 2 ... 3 <entry key="core.debug">0 4 <entry key="max_file_size">100 5 <entry key="accept_extensions">java 6 <entry key="max_validation_time">30 7 <entry key="html_output_type">string 8 <entry key="html_output_dir">data 9 ... 10 Popis atributu: ˚ core.debug Urˇcuje zda se mají veškeré informace (ladící informace, Stack Trace, detailní pozice výskytu chyby) vypisovat do výsledku validace, který bude zaslán uživateli. (0 = vypnuto, 1 = zapnuto) max_file_size Maximální velikost odevzdávaného souboru v kB. Je-li hodnota prázdná, není velikost souboru omezena.


21

accept_extensions Seznam akceptovaných pˇrípon souboru, ˚ oddˇelených cˇ árkou. Je-li uveden znak „*“ jsou akceptovány všechny typy souboru. ˚ max_validation_time Maximální doba celého procesu validace ve vteˇrinách. html_output_type Definuje, jakým zpusobem ˚ se bude generovat výsledek validace pro uživatele. (file = výsledek bude uložen do souboru, string = výsledek bude uložen do rˇetˇezce typu String). html_output_dir Název adresáˇre pro ukládání souboru˚ s výsledkem validace. Soubory jsou ukládány jen pokud je atribut html_output_type nastaven na hodnotu file. Detailní seznam a význam všech nastavení je uveden v pˇriložené dokumentaci [25].

KAPITOLA 4. REALIZACE

22

4 Realizace Tato kapitola podrobnˇe popisuje hlavní body realizace Odevzdávacího systému. Je rozdˇelena do 4 cˇ ástí. První cˇ ást je vˇenována návrhu databázového modelu. Druhá je zamˇerˇena na realizaci modulu pro vyhledávání duplicitních prací. Další cˇ ást popisuje modifikaci dodaného validátoru zdrojových kódu. ˚ Závˇer kapitoly je vˇenován uživatelskému rozhraní aplikace.

4.1 Návrh databáze Pˇred samotným použitím JPA (viz kap. 3.1.6.1 „Java Persistence API“) je nutné vytvoˇrit jeho konfiguraˇcní nastavení. Vybrat perzistentní objekty k mapování, urˇcit typ používané databáze a nastavit všechny náležitosti pˇripojení (server, jméno a heslo). 4.1.1

Konfigurace JPA

Konfigurace JPA je nastavena pomocí XML souboru persistence.xml, který je umístˇen v konfiguraˇcním adresáˇri projektu. Jeho obsah je následující: 1 2 7 8 11 <provider>org.hibernate.ejb.HibernatePersistence 12 <properties> 13 <property name="hibernate.connection.username" 14 value="jmeno"/> 15 <property name="hibernate.connection.driver_class" 16 value="com.mysql.jdbc.Driver"/> 17 <property name="hibernate.connection.password" 18 value="heslo"/> 19 <property name="hibernate.connection.url" 20 value="jdbc:mysql://localhost:3306/odevsys"/> 21 <property name="hibernate.hbm2ddl.auto" 22 value="update"/> 23 <property name="hibernate.show_sql" 24 value="false" /> 25 26 27 V rámci souboru je definována jedna perzistenˇcní jednotka s názvem „OdevzdavaciSystemPU“, která je konfigurovaná pro použití ORM Hibernate [8] a databáze MySQL [22]. V souboru muže ˚ být umístˇeno nˇekolik perzistentních jednotek a je možné mezi nimi vybírat bez jakéhokoli vlivu na funkˇcnost aplikace.


23

Vlastnost hibernate.hbm2ddl.auto nastavená na hodnotu update zaruˇcuje automatické generování databázového schématu podle vytvoˇreného objektového modelu a definic mapování. Hibernate bude automaticky vytváˇret tabulky pro nové entity, aktualizovat metadata týkající se sloupcu, ˚ pˇrípadnˇe automaticky pˇridávat nebo odebírat nové sloupce. To vše na základˇe zmˇen objektového modelu. Bˇehem vývoje aplikace byla vlastnost hibernate.show_sql nastavená na hodnotu true. Tato vlastnost povoluje vypisovat na výstup SQL1 dotazy, které Hibernate bˇehem ukládání a získávání objektu˚ automaticky generuje. To muže ˚ pomoci k vylepšení pˇrípadných dotazu. ˚ 4.1.2

Vytvoˇrení entity

Všechny vytvoˇrené entity je možné prohlédnout ve zdrojovém kódu na pˇriloženém CD. Níže uvedené fragmenty entit slouží pro pˇredstavení nejvýznamnˇejších nastavení nˇekterých vlastností. Ve zdrojovém kódu jsou použity tzv. anotace, které byly zmínˇeny v kapitole 3.1.6.2 „Anotace“. První fragment popisuje dvˇe entity User (uživatel) a Subject (pˇredmˇet) a vytváˇrí mezi nimi obousmˇerné M:N spojení. Obousmˇerné spojení zabezpeˇcuje pˇrístup v obou smˇerech, tj. z uživatele se dají pˇreˇcíst jeho pˇredmˇety a z pˇredmˇetu se dají pˇreˇcíst všichni zapsaní uživatelé. Pˇri použití obousmˇerného spojení je nutné ve vazební anotaci jedné z entit uvést atribut mappedBy a nastavit mu hodnotu na jméno propojeného atributu z druhé entity. Pokud by tento atribut nebyl uveden, vznikly by dvˇe vazby typu 1:1 a jeden objekt by byl do databáze ukládán dvakrát, tj. jedenkrát pro každou stranu vazby. Pro pˇridání uživatele do urˇcitého pˇredmˇetu muže ˚ pomoci metoda addUser(User user), která pˇridá uživatele do pˇredmˇetu jen pokud v nˇem ještˇe není a taktéž pˇridá pˇredmˇet uživateli, jen pokud ho ještˇe nemá. Další atribut, který je použit ve vazebním spojení je cascade. Tento atribut specifikuje operace, které se mají provést na asociované objekty. Hodnota CascadeType.REMOVE rˇíká, že s vymazáním pˇredmˇetu budou odstranˇeni i všichni jeho uživatelé, kteˇrí nejsou souˇcástí jiného pˇredmˇetu. Atribut muže ˚ dále nabývat hodnot MERGE, PERSIST, REFRESH a ALL. Atribut strategy a jeho hodnota GenerationType.AUTO nastavuje generování hodnoty id na automatické. Tento zpusob ˚ generování identifikátoru je použit u všech typu˚ entit v projektu. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

@Entity public class User implements Serializable { ... @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @ManyToMany(mappedBy = "users") private List<Subject> subjects = new ArrayList<Subject>; ... } @Entity public class Subject implements Serializable { ... @ManyToMany(cascade=CascadeType.REMOVE) @Column(nullable = true) private List<User> users = new ArrayList<User>();

1 SQL (Structured Query Language) - standardizovaný dotazovací jazyk používaný pro práci s daty v relaˇcních databázích.

KAPITOLA 4. REALIZACE 19 20 21 22 23 24 25 26 27 28 }

24

... public void addUser(User user) { if (!getUsers().contains(user)) { getUsers().add(user); } if (!user.getSubjects().contains(this)) { user.getSubjects().add(this); } }

Druhý fragment popisuje entitu Work (úloha) a její atribut checkFiles. Tento atribut uchovává kontrolní soubory pro danou úlohu a protože soubory nejsou uloženy ve formˇe základních datových typu, ˚ je nutné u deklarace atributu uvést anotaci @CollectionOfElements. Souˇcástí anotace je atribut fetch a jeho hodnota FetchType.EAGER. Tato vlastnost zaruˇcí, že se spoleˇcnˇe s úlohou budou naˇcítat všechny její kontrolní soubory a budou pˇrístupné i po uzavˇrení Entity Manageru (viz kap. 3.1.6.4 „Životní cyklus entity“). Opaˇcnou hodnotou k FetchType.EAGER je FetchType.LAZY, která pˇri otevˇreném Entity Manageru naˇcítá jen podle potˇreby. Ale po uzavˇrení Entity Manageru jsou data nedostupná. Další atribut, který je ve fragmentu uveden je columnDefinition. Tato vlastnost definuje na jaký typ sloupce bude atribut entity transformován. V uvedeném pˇríkladu je to na typ sloupce longblob, který umožnuje ˇ ukládat soubory až do velikosti 4 294 967 295 bytu. ˚ 1 2 3 4 5 6 7 8 9

@Entity @Table(name = "workItem") public class Work implements Serializable { ... @CollectionOfElements(fetch=FetchType.EAGER) @Column(columnDefinition = "longblob") private Set<SendFile> checkFiles = new HashSet<SendFile>(); ... }

4.2 Modul vyhledávání duplicitních prací Úkolem modulu pro vyhledávání duplicitních prací je najít v ohromném množství všech odevzdaných souboru˚ takové soubory, které jsou si velice podobné a muže ˚ se jednat o opis. Jak bylo zmínˇeno v cˇ ásti 3.2.2 „Princip funkce“ vyhledávání duplicitních prací je rozdˇeleno do tˇrech základních úrovní. Úrovnˇe se liší dukladností ˚ vyhledání a cˇ asovou nároˇcností. 4.2.1

Realizace 1. úrovnˇe vyhledávání

Fragment kódu realizující první úrovenˇ vyhledávání duplicitních prací je uveden níže. Obsah každého souboru je v databázi uložen jako pole bytu. ˚ Pˇred samotným porovnáním obsahu každých dvou souboru˚ je nejprve porovnána velikost tˇechto polí (ˇrádek 1) a je-li ruzná, ˚ pˇrejde se k dalšímu souboru (ˇrádek 2). Pokud je velikost polí stejná, zaˇcne se jejich obsah byte po bytu porovnávat (ˇrádek 5). Jsouli bˇehem porovnávání na stejném indexu polí nalezeny ruzné ˚ hodnoty, pˇrejde se k dalšímu souboru (ˇrádek 6). Pokud je obsah polí naprosto identický, jsou práce oznaˇceny jako duplicitní (ˇrádek 10).

KAPITOLA 4. REALIZACE 1 2 3 4 5 6 7 8 9 10

25

if (pattern.length != collator.length) { continue nextFile; } else { for (int k = 0; k < collator.length; k++) { if (pattern[k] != collator[k]) { continue nextFile; } } } duplicate = true;

4.2.2


Druhá úrovenˇ vyhledávání je shodná s první úrovní, ale pˇred porovnáním obsahu každých dvou polí jsou ze zdrojových kódu˚ vymazány všechny komentáˇre, bílé znaky, názvy tˇríd a metod a identifikátory package a import. K nalezení a vymazání všech tˇechto vlastností je použita metoda replaceAll(String regex, ˇ ezec regex obsahuje regulární výraz pro nalezení String replacement) tˇrídy String. Retˇ ˇ ezec replacement urˇcuje, cˇ ím se má nalezený podˇretˇezec nahradit. urˇcitého podˇretˇezce. Retˇ Více informací k regulárním výrazum ˚ je k nalezení na [26]. 4.2.2.1

Odstranˇení komentáˇru˚

Následující text této cˇ ásti popisuje vývoj regulárního výrazu sloužícího k odstranˇení všech komentáˇru˚ ze zdrojového kódu. Informace v této cˇ ásti jsou cˇ erpány z [27]. První pokus /\*.*\*/ Výraz najde zaˇcátek komentáˇre (/\*), jakýkoli znak nebo cˇ íslo (.*)a konec komentáˇre (\*/). Problém je, že .* nedokáže najít konec rˇádku, takže kompletní výraz nedokáže najít víceˇrádkové komentáˇre. Druhý pokus /\*(.|[\r\n])*\*/ Tento výraz najde i víceˇrádkové komentáˇre, ale zárovenˇ do komentáˇre zaˇradí i cˇ ást kódu, který by mohl být mezi dvˇema komentáˇri. Tˇretí pokus /\*([^*]|[\r\n])*\*/ Tento zpusob ˚ opomíjí víceˇrádkové komentáˇre, které na každém rˇádku zaˇcínají hvˇezdiˇckou. ˇ Ctvrtý pokus /\*([^*]|[\r\n]|(\*([^/]|[\r\n])))*\*/ ˇ Ctvrtý výraz dokáže najít i víceˇrádkové komentáˇre, které na každém rˇádku zaˇcínají hvˇezdiˇckou, ale má stejný problém jako výraz ve druhém pokusu. Zárovenˇ do komentáˇre zaˇradí i cˇ ást kódu, který by mohl být mezi dvˇema komentáˇri. ˇ Rešení (/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|(//.*) Poslední výraz dokáže najít všechny typy komentáˇru, ˚ ty které jsou uvozeny /* */ i jednoˇrádkové komentáˇre zaˇcínající //. Po úpravˇe rˇešení pro jazyk Java a doplnˇení do metody replaceAll, jsou všechny komentáˇre ve zdrojovém souboru vymazány takto: fc = fc.replaceAll( "(?:/\\*(?:[^*]|(?:\\*+[^*/]))*\\*+/)|(?://.*)|(?:\\s)", "");

KAPITOLA 4. REALIZACE 4.2.2.2

26

Odstranˇení ostatních vlastností

Bílé znaky, názvy tˇríd a metod a identifikátory package a import jsou odstranˇeny podobným zpusobem ˚ jako komentáˇre: fc = fc.replaceAll("\\s", ""); fc = fc.replaceAll("class+\\s+\\S+;?", ""); fc = fc.replaceAll("(public|private|static)+[^)]+", ""); fc = fc.replaceAll("package+\\s+\\S+;?", ""); 4.2.3


Tˇretí úrovenˇ vyhledávání rozšiˇruje druhou úrovenˇ o odstranˇení názvu všech identifikátoru˚ a o porovnání poˇradí klíˇcových slov. Seznam klíˇcových slov použitých pro programovací jazyk Java je uveden v kapitole 3.2.2 „Princip funkce“. Pro vyhledání klíˇcových slov jsou použity metody balíˇcku java.util.regex [24], urˇcené pro práci s regulárními výrazy. Souˇcástí zmínˇeného balíˇcku jsou mimo jiné dvˇe tˇrídy Pattern a Matcher. Práci s tˇemito tˇrídami pˇredstavuje níže uvedený fragment kódu, který slouží pro vyhledání klíˇcových slov v souboru: 1 2 3 4 5 6

String keywordPattern = ""; Pattern p = Pattern.compile("ˇ retˇ ezec s klíˇ covými slovy"); Matcher m = p.matcher(patternFileContent); while (m.find()) { keywordPattern += m.group(); }

Metoda compile(String regex) tˇrídy Pattern „pˇrekládá“ vzor, který se bude vyhledávat (ˇretˇezec s klíˇcovými slovy) do interní formy (ˇrádek 2). Metoda matcher() slouží k porovnání zadaného vzoru s rˇetˇezcem typu String, který pˇredstavuje obsah kontrolovaného souboru (ˇrádek 3). Metoda find() tˇrídy Matcher hledá od zaˇcátku rˇetˇezce s obsahem souboru výskyt cˇ ásti, která odpovídá vzoru (ˇrádek 4). Pˇri každém dalším volání metoda hledá další výskyt odpovídající vzoru, tj. lze postupnˇe vyhledat všechny výskyty odpovídající vzoru. Každý naposled nalezený výskyt pˇri posledním volání metodou find() lze získat pomocí metody group(). Všechny nalezené cˇ ásti jsou ukládány do rˇetˇezce keywordPattern (ˇrádek 5). Stejným zpusobem ˚ jsou vyhledána klíˇcová slova ve druhém kontrolovaném souboru a následnˇe ukládána do rˇetˇezce keywordCollator. Oba rˇetˇezce po této fázi obsahují všechna klíˇcová slova v takovém poˇradím, v jakém byla uvedena ve zdrojových souborech a mohou být porovnána metodou obdobnou pˇredchozím fázím.

4.3 Modul importování uživatelu˚ Modul importování uživatelu˚ slouží k hromadnému importu dat naˇctených ze souboru do Odevzdávacího systému. Každý takový soubor musí mít pˇredem definovanou strukturu, která pˇresnˇe popisuje jeho obsah.

KAPITOLA 4. REALIZACE 4.3.1

27

ˇ Ctení XML šablony

V kapitole 3.3.3 „XML šablona“ je uvedena šablona XML souboru urˇceného pro hromadný import uživatelu. ˚ Pro cˇ tení toho souboru je použit DOM2 parser, který naˇcte jeho obsah do pamˇeti a pˇrevede jej na objektový model. Uvedený fragment kódu pˇreˇcte obsah tagu nickname, ve kterém je uvedeno uživatelské jméno. Obdobným zpusobem ˚ jsou pˇreˇcteny ostatní vlastnosti. Metoda parse tˇrídy DocumentBuilder pˇrevede obsah XML souboru na objektový model (ˇrádek 5). Metoda getDocumentElement tˇrídy Document zajistí pˇrímý pˇrístup ke koˇrenovému elementu a metoda normalize pˇrevede obsah tohoto koˇrenového elementu do normalizované formy (ˇrádek 6). Normalizovaná forma pˇredstavuje strukturu dokumentu bez komentáˇru, ˚ referencí apod. Vlastnosti ostatních metod jsou zˇrejmé. Jejich detailní popis je k nalezení v balíˇccích javax.xml.parsers a org.w3c.dom na [24]. 1 try { 2 DocumentBuilderFactory dbf = 3 DocumentBuilderFactory.newInstance(); 4 DocumentBuilder db = dbf.newDocumentBuilder(); 5 Document doc = db.parse(file); 6 doc.getDocumentElement().normalize(); 7 8 if (doc.getDocumentElement().getNodeName().equals("import")) { 9 NodeList userList = doc.getElementsByTagName("user"); 10 11 for (int i = 0; i < userList.getLength(); i++) { 12 Node userNode = userList.item(i); 13 14 if (userNode.getNodeType() == Node.ELEMENT_NODE) { 15 Element userElement = (Element) userNode; 16 17 NodeList nicknameList = 18 userElement.getElementsByTagName("nickname"); 19 Element nicknameElement = 20 (Element) nicknameList.item(0); 21 NodeList nickname = 22 nicknameElement.getChildNodes(); 23 String nickname = 24 ((Node) nickname.item(0)).getNodeValue(); 25 ... 26 } 27 } 28 } 29 } catch (Exception e) { 30 // chyba pˇ ri práci s dokumentem 31 } Všechny hodnoty z takto pˇreˇcteného dokumentu jsou uloženy v rˇetˇezcích typu String a jsou použity pˇri vytvoˇrení nového uživatele (viz kap. 3.1.6.3 „Entity Manager a práce s objekty“). 2

Document Object Model - API umožnující ˇ pˇrístup cˇ i modifikaci obsahu a struktury dokumentu


28

4.4 Validátor zdrojových kódu˚ Validátor dodaný Západoˇceskou univerzitou v Plzni umožnuje ˇ pˇrijmout a pˇreložit jen jednoduché zdrojové kódy, jejichž složitost nepˇresáhne jeden soubor. Navíc je nutné, aby byl vzorový program pro každou úlohu umístˇen na serveru. A název každého zaslaného souboru musí obsahovat speciální prefix, který úlohu identifikuje. To je pro potˇreby pˇredmˇetu˚ vyuˇcoˇ vaných na Fakultˇe elektrotechnické Ceského vysokého uˇcení technického v Praze nepˇrijatelné, protože studenti jsou vedeni pˇredevším k objektovému stylu programování, kdy je nutné vytváˇret více tˇríd, které mohou být zárovenˇ rozmístˇeny do více souboru. ˚ Navíc je zbyteˇcné studenty zatˇežovat starostmi o správném názvu odevzdávaného souboru. 4.4.1

Zaslání souboru˚ k validaci

Vˇetšinu úloh vytvoˇrených pomocí programovacího jazyka Java je lepší naprogramovat do více tˇríd. Aby bylo možné takovou úlohu pomocí použitého validátoru pˇrekontrolovat, je nutné všechny její soubory pˇresunout na validaˇcní server, pˇreložit je a validátoru sdˇelit jméno tˇrídy s metodou main. Odevzdávací systém i validátor jsou umístˇeny na stejném serveru, proto je pˇresun souboru˚ velice jednoduchý. Pro každý zaslaný soubor je vytvoˇrena nová instance tˇrídy java.io.File s parametrem pathname, který odkazuje na validaˇcní složku vybrané domény. Následnˇe je do novˇe vytvoˇrených souboru˚ pˇrekopírován obsah puvodních ˚ odevzdaných souboru. ˚ Stejným zpusobem ˚ jsou ve validaˇcní složce vytvoˇreny nové soubory se vstupními testovacími daty. Všechny novˇe vytvoˇrené soubory, které jsou již umístˇeny ve validaˇcní složce je nutné pˇreložit. Pˇreklad tˇechto souboru˚ provádí zdrojový kód uvedený níže. Detailní popis použitých metod je k nalezení v balíˇcku javax.tools na [24]. Metoda getSystemJavaCompiler tˇrídy ToolProvider inicializuje Java pˇrekladaˇc použité platformy (ˇrádek 4). Metoda getStandardFileManager tˇrídy JavaCompiler vytvoˇrí novou instanci správce souboru˚ (ˇrádek 6). Metoda getJavaFileObjects tˇrídy StandardJavaFileManager naˇcte pole souboru˚ do použitého správce souboru˚ (ˇrádek 8) a vytvoˇrí abstrakci tˇechto souboru˚ pro inicializovaný Java pˇrekladaˇc (ˇrádek 7). Metoda getTask tˇrídy JavaCompiler sestaví úlohu pro pˇreklad (ˇrádek 9) a metoda call tˇrídy CompilationTask úlohu vykoná a všechny soubory pˇreloží (ˇrádek 10). Na závˇer metoda close tˇrídy StandardJavaFileManager zapíše všechny pˇreložené soubory a uzavˇre správce souboru˚ (ˇrádek 12). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/* pole soubor˚ u umístˇ ených ve validaˇ cní složce */ File[] files = ... JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null); Iterable compilationUnits = fileManager.getJavaFileObjects(files); compiler.getTask(null, fileManager, null, null, null, compilationUnits).call(); try { fileManager.close(); } catch (IOException ex) { ... }

Tímto zpusobem ˚ jsou na validaˇcním serveru pˇreloženy jak soubory urˇcené k validaci, tak vzorové soubory, které byly vytvoˇreny zadavatelem úlohy.


29

Jak je zmínˇeno v úvodu této kapitoly, dodaný validátor dokáže pˇrijmout jen jeden zaslaný soubor. Tento soubor byl puvodnˇ ˚ e urˇcen k pˇrenesení zdrojového kódu, ale protože veškerá duležitá ˚ data byla pˇremístˇena jiným zpusobem, ˚ je tento soubor použit k pˇrenosu názvu˚ tˇríd, které obsahují metodu main.

4.5 Uživatelské rozhraní 4.5.1

Autentizace uživatele

Každý uživatel se pˇred pˇrihlášením do systému prokazuje svým pˇrihlašovacím jménem a heslem. Všechna pˇrihlašovací jména a k nim pˇriˇrazená hesla jsou uložena v databázi, odkud jsou po každém pokusu o pˇrihlášení naˇctena a s uživatelem zadanými údaji porovnána. Pokud jsou zadané údaje stejné jako údaje v databázi, je uživatel do systému vpuštˇen. V opaˇcném pˇrípadˇe je uživateli vrácena zpráva s chybou. Nemá-li uživatel v databázi ke svému pˇrihlašovacímu jméno pˇriˇrazené heslo, bude v pˇríˇ padˇe použití systému pro Fakultu elektrotechnickou Ceského vysokého uˇcení technického v Praze použit pro autentizaci interní ovˇerˇovací systém. 4.5.1.1

Autentizaˇcní skript

Pˇripojení k internímu ovˇerˇovacímu systému Fakulty elektrotechnické je provádˇeno za pomoci aplikace s názvem auth_nis_user. Aplikace na svém vstupu pˇrijímá dva parametry, uživatelské jméno a heslo: auth_nis_user username password A na výstupu vrací v pˇrípadˇe správných údaju˚ 0 a v pˇrípadˇe chybných údaju˚ 1. Aplikace je umístˇena na jiném serveru než na kterém funguje Odevzdávací systém, proto je nutné se k ní pro ovˇerˇení správnosti údaju˚ pˇripojit. Pˇripojení na vzdálený server je realizováno zabezpeˇceným komunikaˇcním protokolem SSH3 a autentizace Odevzdávacího systému je ovˇerˇována pomocí RSA4 klíˇce. Pro jednoduché pˇripojování je vytvoˇren skript s názvem auth.sh, který je umístˇen v koˇrenovém adresáˇri Odevzdávacího systému. Obsah skriptu je uveden níže. 1 2 3 4 5 6 7 8 9

#!/bin/bash if [ $1 ]; [ $2 ]; then ssh odevsys@webdev /webdev/ext-auth/auth_nis_user << EOF $1 $2 EOF echo $? fi

Pro podrobné informace o pˇríkazech v použitém skriptu muže ˚ posloužit napˇr. [28]. 4.5.1.2

Spuštˇení autentizaˇcního skriptu

Skript auth.sh, pro ovˇerˇování správnosti uživatelského jména a hesla je umístˇen na pevném disku v adresáˇri Odevzdávacího systému. Pˇripojení k tomuto skriptu, jeho následné spuštˇení 3 4

Secure Shell - zabezpeˇcený komunikaˇcní protokol pro poˇcítaˇcové sítˇe používají TCP/IP Rivest, Shamir, Adleman -šifra s veˇrejným klíˇcem, který je vhodný pro podepisování a šifrování


30

se zadanými parametry a pˇreˇctení výstupu je realizováno pomocí zdrojového kódu uvedeného níže. Detailní popis použitých metod je k nalezení na [24]. ˇ ezce username a password jsou pˇreˇcteny z pˇrihlašovacího formuláˇre a vloženy do Retˇ pˇríkazu na provedení skriptu (ˇrádek 5). Metoda getRuntime tˇrídy Runtime vrací runtime objekt, ve kterém metoda exec spustí pˇríkaz na provedení skriptu (ˇrádek 6). Tím je vytvoˇren nový proces authProcess a pomocí metody getInputStream tˇrídy Process je vrácen jeho výstupní proud, tedy výstup autentizaˇcní aplikace umístˇené na vzdáleném serveru. Následuje pˇreˇctení proudu pomocí instance tˇrídy Scanner a je-li pˇreˇctená hodnota rovna 0, je uživatel úspˇešnˇe pˇrihlášen. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

re */ rihlašovacího formuláˇ /* údaje získané z pˇ String username = ... // uživatelské jméno String password = ... // uživatelské heslo String command = "odevsys/auth.sh " + username + " " + password; Process authProcess = Runtime.getRuntime().exec(command); Scanner sc = new Scanner(authProcess.getInputStream()); if (sc.hasNext()) { if (sc.next().equals("0")) { // úspˇ ešnˇ e pˇ rihlášen } else { rihlašovací údaje // chybné pˇ } }

4.5.2

Lokalizace do více jazyku˚

V této cˇ ásti je popsán zpusob ˚ dynamického naˇcítání lokalizovaných hlášek do webové aplikace postavené na platformˇe JavaServer Faces v jazyce Java. Lokalizace je pˇrizpusobena ˚ prostˇrednictvím Java Internationalization API [29], které umožnuje ˇ vytváˇret textové, datové a jiné výstupy na základˇe jazyka, resp. národnosti uživatele. Lokalizované hlášky jsou naˇcítány z externích souboru˚ typu properties, jejichž název a obsah mají pˇresnˇe definovaný formát: jménoZdroje_jazyk_krajina.properties nebo jménoZdroje_jazyk.properties Každá lokalizovaná hláska je v souboru popsána klíˇcem, který slouží k jejímu vyhledání: // položka souboru Bundle_cs.properties etu redmˇ rení nového pˇ subject_title=Vytvoˇ // položka souboru Bundle_en.properties subject_title=Create new subject Lokalizace uživatelského prostˇredí je zjištˇena pomocí metody getLocale (ˇrádek 2). Naˇctení pˇríslušného properties souboru je realizováno metodou getBundle tˇrídy ResourceBundle, která na svém vstupu oˇcekává dva parametry (ˇrádek 5). Prvním je jméno souboru bez suffixu˚ jazyk


31

a krajina. Druhý parametr je definován instancí tˇrídy Locale a urˇcuje, který jazykový soubor bude naˇcten. Metoda getString tˇrídy ResourceBundle naˇcítá k zadanému klíˇci pˇríslušnou lokalizovanou hlášku (ˇrádek 7). 1 Locale locale = 2 FacesContext.getCurrentInstance().getViewRoot().getLocale(); 3 4 ResourceBundle bundle = 5 ResourceBundle.getBundle("odevzdavacisystem.Bundle", locale); 6 7 String subjectTitle = bundle.getString("subject_title"); Výchozí nastavení jazykové mutace se provádí v XML souboru faces-config.xml, který je uložen v projektovém adresáˇri WEB-INF. Definice cˇ eského prostˇredí jako výchozího (ˇrádek 5) a anglického jako podporovaného (ˇrádek 6) muže ˚ vypadat napˇr. takto: 1 2 ... 3 4 5 <default-locale>cs 6 <supported-locale>en 7 8 <message-bundle>odevzdavacisystem.Bundle 9 10 ... 11

KAPITOLA 5. TESTOVÁNÍ

32

5 Testování Tato kapitola je zamˇerˇena na testování aplikace bˇehem vývoje a po nˇem. V první fázi bylo nutné zjistit, zda implementované rˇešení splnuje ˇ všechny požadavky, které na nˇej byly kladeny. Další fáze byly vˇenovány uživatelskému rozhraní.

5.1 Cíl testování Podstatou je sbírání informací o ovladatelnosti a ergonomii softwaru, který testují ruzné ˚ skupiny uživatelu. ˚ Kritériem pro hodnocení pˇritom muže ˚ být napˇr. cˇ as potˇrebný k vykonání urˇcitého úkolu, poˇcet nutných kliknutí myší, pˇrehlednost apod. Informace od uživatelu˚ jsou postupnˇe vyhodnocovány a na základˇe výsledku˚ probíhá další vývoj.

5.2 Hypotézy H1: Pro uživatele je zpusob ˚ odevzdávání prací pˇres webové rozhraní pˇrínosný. H2: Uživatelum ˚ neˇciní problém doplnit kontrolní rˇetˇezec do odevzdávané práce programovacího charakteru (zdrojový kód). H3: Uživatelé se bez problému˚ pˇrihlásí do webového rozhraní aplikace a odevzdávají práce intuitivnˇe a s jistotou.

5.3 Pˇríprava na testování Pro testování Odevzdávacího systému byl zvolen pˇredmˇet Algoritmizace vyuˇcovaný Katedˇ rou poˇcítaˇcu˚ na Fakultˇe elektrotechnické Ceského vysokého uˇcení technického v Praze. Pˇredmˇet Algoritmizace seznamuje se základy výpoˇcetní techniky a uˇcí jak rˇešit jednoduché úlohy algoritmickým zpusobem ˚ pomocí poˇcítaˇce. Pro demonstraci obecných postupu˚ používá programovací jazyk Java. Pˇredmˇet byl vyuˇcován v jednom semestru (14 týdnu), ˚ a bˇehem nˇeho studenti každý týden odevzdávali domácí úlohy. Úlohy byly programovacího charakteru, tzn. zdrojové kódy napsané v programovacím jazyce Java.

5.4 Harmonogram testování Aplikace byla testována bˇehem jednoho akademického semestru: 1. týden - seznámení uživatelu˚ s aplikací, 2. až 13. týden - samostatné práce studentu˚ na domácích úlohách a jejich odevzdávání, - sbírání informací o chování a chybách systému, 14. týden - distribuce dotazníku s cílem zjistit, co uživatelum ˚ na systému nevyhovuje, co je tˇreba zlepšit a co se jim naopak zamlouvá.


33

5.5 Získání zpˇetné vazby Zpˇetná vazba od uživatelu˚ byla získávána bˇehem celého testovacího období a to: - kontaktním formuláˇrem, umístˇeným v aplikaci na záložce HelpDesk, - emailovými diskusemi, - verbální metodou na cviˇceních pˇredmˇetu, - závˇereˇcným dotazníkem. Možnosti získání zpˇetné vazby: - na cviˇceních pˇredmˇetu uživatelé odevzdávali úlohy vytvoˇrené bˇehem cviˇcení a se svým cviˇcícím uˇcitelem, který zaznamenával jejich chování, pˇrímo konzultovali pˇrípadné problémy s aplikací, - uživatelé odevzdávali domácí úkoly ze svých osobních poˇcítaˇcu, ˚ napˇr. z domácího prostˇredí. Takové prostˇredí by jim mˇelo odstranit nervozitu a pocit, že se jedná o test uživatele namísto aplikace. Pˇrípadné problémy s aplikací byly zaznamenávány pomocí logu˚ a uživatelé je konzultovali pˇres kontaktní formuláˇr umístˇený pˇrímo v prostˇredí aplikace.

5.6 Skupina testujících uživatelu˚ 5.6.1

Požadované profily testujících osob

- vˇek: 18 – 40 let - student VŠ – první roˇcník - rovnomˇerné rozložení uživatelu˚ do 3 skupin:

zvládá základní ovládání PC a nemá zkušenosti s vývojem aplikací, nemá problémy s ovládáním PC a nemá zkušenosti s vývojem aplikací, nemá problémy s ovládáním PC a má zkušenosti s vývojem aplikací.

Díky rozdílným profilum ˚ testujících osob byly získávány odlišné zpˇetné vazby a budoucí vývoj mohl být nasmˇerován smˇerem k pˇriblížení všem skupinám uživatelu. ˚ 5.6.2

Skuteˇcné profily testujících osob

Jak bylo zmínˇeno v cˇ ásti 5.3 „Pˇríprava na testování“, pro testování aplikace byl zvolen pˇredmˇet Algoritmizace. Pˇredmˇet byl vyuˇcován v prezenˇcní a v kombinované formˇe studia. V prezenˇcní formˇe studia byly vˇetšinou „ˇcerství“ maturanti do 20 let. Naopak v kombinované formˇe mˇeli majoritní zastoupení již pracující studenti ve vˇeku od 20 do 40 let. Pro samotné testování byla zvolena jedna skupina z prezenˇcní (19 studentu) ˚ a jedna skupina z kombinované (108 studentu) ˚ formy studia.

5.7 Závˇereˇcný dotazník Dotazník distribuovaný uživatelum ˚ aplikace na konci semestru byl rozdˇelen na dvˇe cˇ ásti. První cˇ ást mˇela za cíl zjistit poˇcítaˇcovou gramotnost uživatele od základních po pokroˇcilé znalosti. Druhá cˇ ást byla zamˇerˇena na samotný Odevzdávací systém, pˇredevším na funkˇcnost aplikace a ergonomii uživatelského rozhraní.

KAPITOLA 5. TESTOVÁNÍ 5.7.1

První cˇ ást dotazníku

1. Kolik je Vám let (jedna odpovˇed’): a) ménˇe než 25 b) 26 – 30 c) 31 – 35 d) 36 – 40 e) více než 41 2. Nejvyšší ukonˇcené vzdˇelání (jedna odpovˇed’): a) vyuˇcen(a) s maturitou b) gymnázium c) stˇrední odborná škola d) vysokoškolské e) jiné 3. Jak cˇ asto používáte poˇcítaˇc (jedna odpovˇed’): a) nikdy b) párkrát do mˇesíce c) párkrát do týdne d) každý den 4. Kde všude pracujete s poˇcítaˇcem (více odpovˇedí): a) v práci b) ve škole c) doma d) jinde 5. Pracujete-li s poˇcítaˇcem v práci, k jakému úˇcelu jej používáte (více odpovˇedí): a) programování (jakékoli) b) práce s programy typu MS Word, Excel apod. c) jiné, doplnte: ˇ 6. Jaké technologie doposud znáte (více odpovˇedí): a) HTML, CSS b) JavaScript, DOM c) PHP, JSP d) Java e) C, C++ f) C#, J# g) SQL h) jiné, doplnte: ˇ

34


35

7. Nauˇcit se programovací jazyk Java pro Vás bylo (jedna odpovˇed’): a) jednoduché b) mírnˇe obtížné c) obtížné d) nemožné 5.7.2

Úˇcel sledování otázek v první cˇ ásti dotazníku

1. otázka - rozdˇelení do skupin podle vˇeku uživatelu˚ 2. otázka - rozdˇelení do skupin podle dosaženého vzdˇelání a poˇcítaˇcové gramotnosti 3. otázka - rozdˇelení do skupin podle zkušeností s poˇcítaˇcem 4. a 5. otázka - upˇresnˇení skupin pro zkušenosti s poˇcítaˇcem 6. otázka - rozdˇelení do skupin podle poˇcítaˇcové gramotnosti 7. otázka - upˇresnˇení skupin pro poˇcítaˇcovou gramotnost 5.7.3

Druhá cˇ ást dotazníku

1. Setkal(a) jste se nˇekdy s odevzdávacím systémem podobného typu (jedna odpovˇed’): a) ano b) ne 2. Když jste poprvé pˇres Odevzdávací systém odevzdával(a) úlohu bylo to pro Vás (jedna odpovˇed’): a) jednoduché b) mírnˇe obtížné c) obtížné d) nemožné 3. Myslíte si, že je správné dopˇredu znát testovací data (jedna odpovˇed’): Pˇredstavte si napˇr. úlohu na rˇešení lineárních rovnic. Programátor napíše aplikaci pro testovací data, která dopˇredu zná a nemusí vubec ˚ pˇremýšlet nad tím, jaké situace by mohly nastat (žádné rˇešení, nekoneˇcnˇe mnoho rˇešení, atd.).

a) ano b) ne


36

4. Jaké funkce Vám v Odevzdávacím systému chybí: 5. Jakým zpusobem ˚ byste zmˇenil(a) vzhled: Vzpomente ˇ napˇr. na umístˇení a vzhled varovných hlášení, na seznam zadaných úloh nebo na zobrazení zadání úlohy.

6. Máte nˇejaké jiné pˇripomínky k Odevzdávacímu systému, tomuto dotazníku nebo k samotnému pˇredmˇetu Algoritmizace: 5.7.4

Úˇcel sledování otázek ve druhé cˇ ásti dotazníku

1. otázka - zjištˇení, zda má uživatel zkušenosti se systémem podobného typu - pokud ano, muže ˚ svými zkušenostmi výraznˇe pˇrispˇet 2. otázka - zjištˇení, zda prvotní pˇredstavení aplikace a zpracování uživatelského manuálu bylo dostateˇcné 3. otázka - testovací data jsou vstupní hodnoty, pomocí kterých jsou kontrolovány odevzdané práce (bˇehem testování nebyla zveˇrejnována) ˇ - na tuto otázku má velký vliv poˇcítaˇcová gramotnost uživatele a jeho zkušenosti s programovacími jazyky - bude-li odpovˇed’ pokroˇcilého uživatele kladná, je na pováženou zda testovací data dále nezveˇrejnovat ˇ 4. otázka - zjištˇení, jak systém dále zlepšit, pˇrípadnˇe o které funkce jej rozšíˇrit 5. otázka - zjištˇení, jak zlepšit ergonomii a ovladatelnost systému 6. otázka - zjištˇení, jak dále upravit Odevzdávací systém, tento dotazník a pˇredmˇet Algoritmizace 5.7.5

Dˇelení uživatelu˚ do skupin

Odpovˇedi na otázky 2 až 7 z první cˇ ásti dotazníku a na otázku cˇ . 1 z druhé cˇ ásti dotazníku byly obodovány (viz tab. 5.2) a uživatelé byli podle poˇctu získaných bodu˚ rozdˇeleni do tˇrech skupin podle zkušeností – zaˇcáteˇcník, prumˇ ˚ erný a pokroˇcilý. Bodové oznaˇcení jednotlivých odpovˇedí bylo vybráno tak, aby dˇelení do skupin pro každou otázku (tj. skupiny rozdˇelené podle dosaženého vzdˇelání a gramotnosti, podle zkušeností s poˇcítaˇcem a podle poˇcítaˇcové gramotnosti) bylo co nejlépe aplikováno na skupiny zacˇ áteˇcník, prumˇ ˚ erný, pokroˇcilý (viz tab. 5.1). Byly-li odpovˇedi na ostatní otázky, které se týkaly zlepšení aplikace, v rozporu, byla uprˇednostnˇena odpovˇed’ uživatele z vyšší skupiny (zaˇcáteˇcník < prumˇ ˚ erný < pokroˇcilý).


37

Uživatelská skupina

Poˇcet bodu˚

zaˇcáteˇcník

< 10

prumˇ ˚ erný

10 - 13

pokroˇcilý

> 13

Tabulka 5.1: Rozdˇelení uživatelu˚ do skupin podle poˇctu bodu˚ z vyplnˇeného dotazníku.

5.8 Prubˇ ˚ eh testu 5.8.1

Seznámení uživatelu˚ s aplikací

Bˇehem prvního týdne semestru byli uživatelé na cviˇcení pˇredmˇetu Algoritmizace seznámeni s aplikací a s jejími funkcemi. Jako první jim byla sdˇelena webová adresa, kde se aplikace nachází a zpusob ˚ jak se pˇrihlásit. Po pˇrihlášení se všem zobrazil manuál, popisující prostˇredí systému a zpusoby, ˚ jak s ním pracovat. Manuál byl zjednodušenˇe pˇrednesen. Pˇredevším byla zduraznˇ ˚ ena cˇ ást o pˇridání rˇádku do zdrojového kódu, který do výstupu vypisuje rˇetˇezec „—Vysledky—“. Díky tomu validátor pozná, která výstupní data kontrolovat. Na závˇer cviˇcení byla zadána programovací úloha, kterou všichni mˇeli vypracovat a odevzdat. Zadání úlohy: Napište program, který z klávesnice pˇreˇcte dvˇe celá cˇ ísla a na výstupu vypíše jejich souˇcet. Jedno z možných rˇešení: 1 2 3 4 5 6 7 8 9 10 11 12 13 5.8.2

import java.util.Scanner; public class Soucet { public static void main(String[] args) { Scanner sc = new Scanner(System.in); System.out.print("Zadej a: "); int a = sc.nextInt(); System.out.print("Zadej b: "); int b = sc.nextInt(); System.out.println("---Vysledky---"); System.out.println("Soucet je: " + (a+b)); } } Testování aplikace

Od druhého do tˇrináctého týdne byly v prostˇredí aplikace zveˇrejnovány ˇ další domácí úlohy, které uživatelé bˇehem celého semestru vypracovávali a odevzdávali. Studenti z prezenˇcní formy studia, kteˇrí mˇeli cviˇcení každý týden, navíc odevzdávali úlohy vypracované bˇehem cviˇcení a pˇrípadné komplikace konzultovali pˇrímo s uˇcitelem, který vše textovˇe zaznamenával. Neoˇcekávané události (napˇr. chyba pˇri spojení s databázovým serverem, výpadek vali-


38

odpovˇed’

vyuˇcen(a) s maturitou

gymnázium

stˇrední odborná škola

vysoká škola

poˇcet bodu˚

0

+1

+1

+2

odpovˇed’

nikdy

párkrát do mˇesíce

párkrát do týdne

každý den

poˇcet bodu˚

-4

-3

-1

0

2. otázka I. dotazník


odpovˇed’

každá vybraná

poˇcet bodu˚

+1


odpovˇed’

programování

MS Word apod.

jiné

poˇcet bodu˚

+2

+1

+1


odpovˇed’

každá vybraná

poˇcet bodu˚

+1


odpovˇed’

jednoduché

mírnˇe obtížné

obtížné

nemožné

poˇcet bodu˚

+2

+1

0

-1


odpovˇed’

ano

ne

poˇcet bodu˚

+3

0

1. otázka II. dotazník

Tabulka 5.2: Bodové ohodnocení otázek ze závˇereˇcného dotazníku.


39

daˇcního serveru apod.) byly zaznamenávány samotnou aplikací do speciálnˇe vyhrazeného úložištˇe. 5.8.3

Dotazník

V prubˇ ˚ ehu posledního cˇ trnáctého týdne semestru byl mezi uživatele prostˇrednictvím aplikace distribuován dotazník, s cílem zjistit, co je nutné zlepšit a co se uživatelum ˚ naopak zamlouvá.

5.9 Výsledky testu Z celkového poˇctu 19 studentu˚ prezenˇcní a 108 studentu˚ kombinované formy studia se testování od zaˇcátku do konce semestru úˇcastnilo 13 studentu˚ z prezenˇcní a 66 studentu˚ z kombinované formy studia. Bylo to zapˇríˇcinˇeno pˇredevším tím, že studenti bˇehem semestru ukonˇcili studium nebo vubec ˚ neodevzdávali domácí úlohy. 5.9.1

Pˇrihlášení do systému

Bˇehem první dekády testování bylo zjištˇeno, že mnozí uživatelé neznají své pˇrihlašovací heslo do prostˇredí aplikace. Jednalo se o studenty prvního roˇcníku, kteˇrí rˇádnˇe netušili, jak školní poˇcítaˇcová sít’ funguje a kde heslo získat. Ihned po zjištˇení této skuteˇcnosti bylo prostˇredí s pˇrihlašovacím formuláˇrem rozšíˇreno o textové pole s popisem, kde a jakým zpusobem ˚ heslo získat (obr. 5.1).

Obrázek 5.1: Textové pole s popisem, kde a jakým zpusobem ˚ získat heslo pro pˇrihlášení.

5.9.2

Odevzdání první úlohy

Po prvních dvou týdnech mˇeli všichni uživatelé úspˇešnˇe odevzdanou úlohu, která byla zadána na prvním cviˇcení. 33 uživatelu˚ mˇelo s odevzdáním problém, z toho bylo 6 programovacího rázu a 27 s chybˇejícím kontrolním rˇetˇezcem „—Vysledky—“ (viz tab. 5.3). Uživatelé, kteˇrí opomnˇeli pˇridat rˇádek s kontrolním rˇetˇezcem, byli bˇehem odevzdávání aplikací upozornˇeni a všichni prumˇ ˚ ernˇe do tˇrí minut od chybného odevzdání zdrojový kód


40

chybˇející kontrolní rˇetˇezec

chybnˇe naprogramováno

úspˇešnˇe odevzdáno

27

6

46

poˇcet uživatelu˚

Tabulka 5.3: Úspˇešnost odevzdání první úlohy. opravili a úlohu úspˇešnˇe odevzdali (obr. 5.2). Do zmínˇených tˇrech minut je nutné zapoˇcítat pˇrípadné spuštˇení vývojového prostˇredí, doplnˇení chybˇejícího rˇádku v kódu, pˇrípadné znovupˇrihlášení do aplikace Odevzdávacího systému a odevzdání. Z toho lze usoudit, že uživatelé po upozornˇení na chybu s chybˇejícím kontrolním rˇetˇezcem nemˇeli problém s opravou. Pˇri odevzdávání dalších úloh se tento problém vyskytoval prumˇ ˚ ernˇe tˇrikrát na úlohu. Pˇri celkovém poˇctu 79 uživatelu˚ lze usoudit, že se jednalo o opomenutí.

Obrázek 5.2: Zobrazení cˇ asového rozdílu mezi chybným a úspˇešným odevzdáním první úlohy s chybˇejícím kontrolním rˇ etˇezcem.

5.9.3

Odevzdání dalších úloh

Bˇehem semestru se vyskytly 3 závažné problémy s aplikací, na které bylo upozornˇeno bud’ kontaktním formuláˇrem, který je pˇrímo v aplikaci nebo pomocí emailových zpráv. Prvním problémem byla nemožnost úspˇešnˇe validovat nˇekteré odevzdané úlohy, pˇrestože na osobních poˇcítaˇcích uživatelu˚ fungovaly bez problému. ˚ Zdrojový kód tˇechto úloh obsahoval urˇcitý sled pˇríkazu, ˚ kvuli ˚ kterým validátor do odevzdané úlohy vložil rozdílná vstupní data, než do vzorové úlohy. To zpusobilo ˚ rozdílnost výstupu˚ a oznaˇcení úlohy za neúspˇešnˇe validovanou. Chyba validátoru byla po nˇekolika hodinách od upozornˇení odstranˇena. Druhý problém nastal po vypršení sezení na serveru. Pokud chtˇel pˇrihlášený uživatel po více jak 30 minutách neaktivity provést nˇejaký úkon, zobrazila se na obrazovce chyba serveru a to bez jakékoli zmínky o dlouhé neaktivitˇe. Uživatel nevˇedˇel, proˇc byl odhlášen a pokud právˇe odevzdával nˇejakou úlohu, mohl nabýt dojmu, že byla odevzdána, pˇrestože tomu tak nebylo. Tato chyba byla opravena tím, že pˇrihlášený uživatel je po 25 minutách neˇcinnosti upozornˇen dialogovým oknem se zprávou o blížící se expiraci sezení. Po pˇrekroˇcení 30 minut je uživatel automaticky odhlášen a na obrazovce je zobrazen pˇrihlašovací formuláˇr s hláškou o expiraci. Tˇretí problém se vyskytl zhruba v polovinˇe semestru a mˇel za následek úplnou nefunkˇcnost validátoru. Díky záznamum ˚ o problémech a neˇcinnosti, které systém automaticky ukládá do speciálního úložištˇe, bylo zjištˇeno, že na server, na kterém aplikace bˇeží, byla nainstalována nová verze JDK1 a puvodní ˚ byla odinstalována. Validátor vyžaduje JDK ke správné funkci a ve svém nastavení k nˇemu má uvedenou absolutní cestu. Instalací nové verze byla cesta k JDK zmˇenˇena a to zpusobilo ˚ nefunkˇcnost. Tato chyba byla odstranˇena zmˇenou cesty uvedené v nastavení validátoru na symbolický link, který ukazuje vždy na nejaktuálnˇejší verzi JDK. 1

JDK (Java Development Kit) - množina základních nástroju˚ pro vývoj aplikací na platformˇe Java.

KAPITOLA 5. TESTOVÁNÍ 5.9.4

41

Dotazník

Dotazník byl kompletnˇe vyplnˇen 7 studenty z prezenˇcní a 35 studenty z kombinované formy studia. Poté jak je uvedeno v kapitole 5.7.5 „Dˇelení uživatelu˚ do skupin“ , byly jednotlivé odpovˇedi obodovány a uživatelé rozdˇeleni do skupin podle zkušeností - zaˇcáteˇcník, prumˇ ˚ erný a pokroˇcilý (viz tab. 5.4).


zaˇcáteˇcník

prumˇ ˚ erný

pokroˇcilý

13

18

11

Tabulka 5.4: Rozdˇelení uživatelu˚ do skupin v závislosti na vyplnˇeném dotazníku. Na grafu „Rozdˇelení do skupin podle vˇeku uživatelu“ ˚ (obr. 5.3) je vidˇet, že nejvˇetší poˇcet uživatelu˚ testujících aplikaci je mladších 30 let. Každá vˇeková skupina mimo „> 41“ má alesponˇ jednoho cˇ lena a mimo skupin „36 - 40“ a „> 41“ zahrnuje uživatele ze všech tˇrech zkušenostních kategorií.

Obrázek 5.3: Rozdˇelení do skupin podle vˇeku uživatelu. ˚

5.9.4.1

Odevzdání první úlohy

V kapitole 5.9.2 „Odevzdání první úlohy“ je uvedeno, že 33 uživatelu˚ mˇelo problém s odevzdáˇ ním první úlohy. Na grafu „Cetnost odpovˇedí na 2. otázku z II. dotazníku“ (obr. 5.4) je vidˇet, že pro 20 uživatelu˚ bylo odevzdání jednoduché a pro 22 uživatelu˚ bylo mírnˇe obtížné. Žádný z uživatelu˚ v dotazníku nevybral možnost "obtížné"nebo "nemožné". Z uvedených údaju˚ lze potvrdit tvrzení z kapitoly 5.9.2 „Odevzdání první úlohy“ - uživatelé po upozornˇení na chybu s chybˇejícím kontrolním rˇetˇezcem nemˇeli problém s opravou.


42

ˇ Obrázek 5.4: Cetnost odpovˇedí na 2. otázku z II. dotazníku.

5.9.4.2

Zveˇrejnování ˇ testovacích dat

ˇ Na grafu „Cetnost odpovˇedí na 3. otázku z II. dotazníku“ (obr. 5.5) je vidˇet názor uživatelu˚ na zveˇrejnování ˇ testovacích dat. 13 uživatelu˚ je pro zveˇrejnování ˇ a 29 proti. Zárovenˇ je proti zveˇrejnování ˇ i vˇetší poˇcet uživatelu˚ v jednotlivých zkušenostních kategoriích.

ˇ Obrázek 5.5: Cetnost odpovˇedí na 3. otázku z II. dotazníku.

KAPITOLA 5. TESTOVÁNÍ 5.9.4.3

43

Zmˇena vzhledu a pˇridání funkcí

Odpovˇedi na otázky cˇ íslo 5, 6 a 7 z II. dotazníku, které pˇredstavují vylepšení funkˇcnosti, vzhledu a ergonomie uživatelského rozhraní aplikace jsou seˇrazeny podle zkušeností uživatelu˚ v tabulce 5.5. Odpovˇedi jsou uvedeny v nezmˇenˇené formˇe tak, jak je uživatelé zaznamenaly.

úrovenˇ zkušenosti uživatele

Jaké funkce byste do OdevSysu pˇridal(a)?

Jakým zpusobem ˚ byste zmˇenil(a) vzhled OdevSysu?

zaˇcáteˇcník

presnejsi popis pozadovaeho vystupu cize zadanie, bolo to matuce a nedostacujuce, ale iba v malo pripadoch no predsa

je to o.k.

zaˇcáteˇcník

Vetsi flexibilnost reseni,

Urcite nejaky barvicky a nejakou kostru alespon v css

zaˇcáteˇcník

Neodevzdané práce

zaˇcáteˇcník

zaˇcáteˇcník

vytvoˇrením záložek po uspesnem odevzdani, zobrazit vstupni data, abych vedel kde to presne neproslo a mohl se na to zamerit.

trochu nevyrazne ramecky. spatne se sleduje jestli je uloha odevzdana. ale jinak vyhovujici.

Máte nˇejaké pˇripomínky k OdevSysu, tomuto dotazníku nebo k pˇredmˇetu Algoritmizace?

OdevSys zvalidoval i chybny program, tj. problemy: 1. sire testovacich dat 2. nelze opravit chybny zvalidovany program (ani tesne po odeslani chybneho) - to neni stiznost, pouze konstatovani nejednoznaˇcné zadání úlohy

zatim nemam.

pokraˇcování na další stranˇe ... Tabulka 5.5: Odpovˇedi na otázky týkající se vylepšení funkˇcnosti a vzhledu seˇrazené podle zkušeností jednotlivých uživatelu. ˚


44

... pokraˇcování z pˇredchozí strany


prumˇ ˚ erný

prumˇ ˚ erný

prumˇ ˚ erný

Jaké funkce byste do OdevSysu pˇridal(a)? Možná by bylo fajn napˇr. po nˇejakém poˇctu neúspˇešných odevzdání nebo tˇreba po urˇcité dobˇe pomoci s drobnou nápovˇedou, napˇr. zviditelnˇení již zmínˇených vstupních dat. Jako dálkaˇr bych asi i ocenil po úspˇešném odevzdání tˇreba zviditelnit byt’ jen slovnˇe popsaný "nejefektivnˇejší"algoritmus. Mám tím na mysli, že k výsledku se dá dopracovat ruznými ˚ cestami, ovšem cˇ asová složitost a složitost vubec ˚ už nemusí být vždy ta pravá. Tedy navést, jak je vhodné úlohy daného typu nejlépe rˇešit. Lehkou napovedu, ktera by uzivatele mirne nakopla spravnym smerem k reseni ulohy. moznost odevzdavat i v jinych programovacich jazycich(C#)



Nechal bych ho tak, jak je. Pˇrijde mi pˇrehledný a svuj ˚ úˇcel plní. Nejsou tˇreba vymazlená tlaˇcítka a podobné vymoženosti:-) Proˇc není v nejvyšším dosaženém vzdˇelání vyšší odborná škola?:-)

Jsem dálkaˇr, takže bych ocenil tˇreba více víkendových semináˇru. ˚ Ale je mi jasné, že je to asi mimo možnosti školy a asi i mimo možnosti mnoha spolustudentu. ˚ U nás dálkaˇru˚ je to hodnˇe rychlokurz, cˇ ili je tu pomˇernˇe velký handicap, protože požadavky na znalosti jsou stejné jako u denního studia. Zárovenˇ chápu, že jakkoliv nás zvýhodnovat ˇ je také nefér. Prostˇe je to boj:-)

Myslim si, ze na vzhledu nezalezi. Spise na funkci celeho systemu

bez pripominek

udelat hezci grafiku a barevne

uvital bych moznost odevzdavat ukoly psane v c#



45




prumˇ ˚ erný

Celkem by se hodila moznost po uspesne validaci prikladu dat na vyber zda-li validaci potvrdit ci ne. Konkretne se my jedna o situaci kdy student napise kod ktery ocekava ze bude fungovat, ale o krerem vi ze neni uplne optimalni ale nechce ztracet cas jeho optimalizaci, jelikoz nema 100% jistotu ze kod je validni. V pripade ze bude kod validni odmitne validaci potvrdit a bude moci kod optimalizovat jak nejlepe dovede s jistotou ze nedela zbytecnou praci a ze se dale zdokonaluje. Pri dalsi validaci validaci prijme. Dalsi vyuziti teto pripadne funkcnosti by bylo kdyz studenta napadnou ruzna reseni problemu a obe chce vyzkouset. Mel by pote moznost si vybrat co by se nakonec ukazalo jako lepsi varianta.



Stranka Odevzdání práce je znacne neprakticka, uvital bych kdyby zadani prikladu nebylo v textaree kde pro precteni zadani musim skrolovat mysi neustale sem tam, ale misto toho bylo zadani videt cele bez nutnosti skrolovani. O nutnosti skrolovat na dalsi priklad v tomto pripade nemluvim, to by bylo samozrejme.

Jako vytku bych mel obcasnou nejasnost zadani! Kontretne napr. uloha Meziˇcas kde vubec neni jasne v jakem poradi maji byt zadane casove udaje ci jak s nimi konkretne nalozit. viz ukazkovy priklad Mezi 23:5 a 1:14 ubehlo 1311 min tj. 21 h a 51 min Z tohoto zadani bych logicky usoudil ze 23:5 je jeden den pred pulnoci a 1:14 je druhy den po pulnoci, ale presto je vysledek 21 h a 51 min, coz odpovida tomu ze 1:14 je brzo rano a 23:5 je ten samy den pozde vecer.



46



prumˇ ˚ erný

prumˇ ˚ erný

prumˇ ˚ erný



Pokud validátor vrátí chybu pˇri validaci, bylo by dobré vypsat testovací data, na kterých došlo k chybnému výstupu (aby to programátor nemusel sám v programu ošetˇrovat, když je chce zjistit). Ulehˇcilo by to hledání chyb.

Vzhled bych nemˇenil, nicménˇe v pˇrehledu odevzdaných úloh by se nemusely zobrazovat neúspˇešné pokusy o odevzdání dané úlohy, pokud poté následovalo její úspˇešné odevzdání. Stejnˇe tak by bylo dobré vypisovat v tomto pˇrehledu úlohy, které zbývá ještˇe odevzdat, aby to student nemusel "proklikávat"u všech kategorií zvlášt’.

možnost odeslat více tˇríd najednou pokud by byla úloha rˇešena za použití více tˇríd, kdy jedna bude obsahovat metodu main v prehledu odevzdanych uloh pridani filtru uspesne / neuspesne / vsechny odevzdane

nezáleží

Máte nˇejaké pˇripomínky k OdevSysu, tomuto dotazníku nebo k pˇredmˇetu Algoritmizace? Otevˇrení úlohy v 00:00:01 není zrovna št’astné, jelikož pˇri vazbˇe na datum a cˇ asový limit pro odevzdání to opticky vypadá, že je na odevzdání cˇ asu o den více, než je skuteˇcnost. Lepši by bylo úlohy otevírat od 12:00 nebo od 23:59. Též bych uvítal v pˇrehledu "Odevzdání práce", kdyby se zobrazovalo navíc ještˇe datum a cˇ as odevzdání, do kterého lze získat plný poˇcet bodu, ˚ pˇrípadnˇe toto dynamicky mˇenit podle toho, kolik aktuálnˇe lze za úlohu bodu˚ získat.

ne

lepsi zvyrazneni barevneho oramovani - ne vzdy je barva dobre rozeznatelna pokraˇcování na další stranˇe ...

Tabulka 5.5: Odpovˇedi na otázky týkající se vylepšení funkˇcnosti a vzhledu seˇrazené podle zkušeností jednotlivých uživatelu. ˚


47






prumˇ ˚ erný

Možnost nastavení doby automatického odhlášení, online java IDE rozhraní a kalendáˇr. Po odevzdání by se mohlo vypsat poˇradí v odevzádní. Napˇr. "Tuto úlohu jste odevzdal jako 1.":)

Možná pˇridat trochu barev, hodila by se možnost nastavit si vlastní styl vzhledu (z nˇekolika možností).

Poslední pˇríklad (Bonus. úloha: Nejdelší rostoucí podposloupnost) byla zadána trochu nejednoznaˇcnˇe. Jinak OK.

Vetsi "okenka"se zadanymi ulohami.Videt jen par radku je velice neprivetive.Mozna pro kazdou ulohu dat na novou stranku.

Na nove zadane ulohy by mel byt uzivatel upozornen predem.Odevzdal jsem vsechny ulohy ktere byly vyznaceny v OdevSys a az pote byli pridany nove.Mel jsem vse za vyresene a tak jsem se do OdevSys nedival,zjistil jsem to nahodou tak ze se o tom bavili spoluzaci ve skole.

pokroˇcilý

pokroˇcilý

Vzhled muže ˚ klidnˇe zustat ˚ v stávajícím stavu. Pˇrijde mi ok a navíc jde o aplikaci s durazem ˚ na funkˇcnost, ne o prezentaci (s durazem ˚ na vzhled). pokraˇcování na další stranˇe ...



48



pokroˇcilý

pokroˇcilý



1. možnost odevzdat úlohu opakovanˇe i když byla již jednou odevzdána a prošla. Vzhledem k cˇ asové tisni neni vždy rˇešení to nejlepší ale je funkˇcní. Do konce termínu lze úlohu doladit a cˇ lovˇek muže ˚ odevzdat lepší rˇešení. Mozna zobrazeni aktualniho ziskatelneho poctu bodu k jednotlivym prikladum? Tj. aby student vedel, kolik v danou chvili muze z prikladu skutecne ziskat bodu (prvni tyden maximum, druhy tyden maximum, treti tyden vypoctenou polovinu maxima, ctvrty tyden ctvrtinu maxima, atd.) - aby si to nemusel prepocitavat v hlave.

vzhled bych zásadnˇe nemˇenil. Všechno je nyní rychlé. Jsou zde jednoduché styly a nic se dlouho nenaˇcítá. Pˇridal bych do záhlaví ˇ logo CVUT a do zápatí každné stránky kontakt na zodpovˇednou osobu.

pokroˇcilý


Mozna trosku zweb-2.0-ovatet, tj. aby design vypadal jako z 21. stoleti. Nic osobniho proti autorove volbe designu, sam bych to neudelal lepe :-)

už se teším do budoucna, kdy bude možné podobným zpusobem možné delat i zkoušky odkudkoliv na svete pokraˇcování na další stranˇe ...



49





pokroˇcilý

a) Nevim jestli to neni zbytecne, ale urcite by nekdo ocenil fci nahrazeni kompilacnich chyb.. napr. jestli na nejakem radku chybi strednik, tak by se vypsala hlaska "Zkontrolujte prosim kod na radce blablabla, nechybi vam tam strednik nebo mate tam spravne syntaxi"? Jasne, ze zahrnout vsechny chyby je pracne, ale zacatecnikum to treba pomuze.. b) to me asi studenti nebudou mit v lasce, ale je docela jednoduche zjistit parsovana testovaci data, ktere se momentalne testuji. Z jedne strany ulehci to hledani chyby, ale neda se to zneuzit?

snad jedine pokud je mnozina uloh vyresena bylo by dobre oznacit celou mnozinu napr. zelene.. nebo nakreslit u toho fajvku na strance Odevzdani prace.

pokroˇcilý

Máte nˇejaké pˇripomínky k OdevSysu, tomuto dotazníku nebo k pˇredmˇetu Algoritmizace? pokracovani bodu 11) - bohuzel mi to vypsalo Data too long v tamtom poli... c) bylo by mozna dobre misto Validace: OK uvest podrobnejsi statistiku. Napr. kolik testovacich kol probehlo, slozitost algoritmu, rating clean codu.. pak na konci dne nebo napr. semestru by byla tabulka high score na nejlepsi reseni :)) - ale to uz vypada spis na scifi :))) High score top 10 resitelu s nejvic body nebo nejrychlejsich resitelu kazde ulohy. d) uz snad nic.. tento system je zajimava myslenka, kdyby cely studium na CVUT probihal online pres web bylo by to fajn.

- Vetsi (natahovaci) pole se zadanim prikladu. - OdevSys snadneji U "Odevzdání k nalezni (lepsi práce"- tabulka adresa, odkaz ze temat zobrazit pocet stranek predmetu) uloh (splnene/celkem), pocet bodu. pokraˇcování na další stranˇe ...



50




pokroˇcilý

Každopádnˇe tu funkci oznamování zmˇen (otevˇrení, uzavˇrení, blížící se "pulení ˚ bodu"a ˚ všech dalších možných, samozˇrejmˇe uživatelem definovatelných) emailem na uživatelem definovanou adresu. To by bylo opravdu super! Odhlašování po pul ˚ hodinˇe je docela opruz, dal bych cˇ as nastavitelný uživatelem.

Máte nˇejaké pˇripomínky Jakým zpusobem ˚ k OdevSysu, byste zmˇenil(a) tomuto dotazníku vzhled OdevSysu? nebo k pˇredmˇetu Algoritmizace? Zaprotestoval proti "pulení"bod ˚ u. ˚ Ikdyž chápu, že je to marné :) Obˇcas cˇ lovˇeka nakrkne nepˇresný popis požadovaného algoritmu, když to pak odevsys nezchroustne, ale to je spíš na cˇ lovˇeku, co to tam pˇridává... a to je život. V tomto dotazníku jsem jenom trochu nepobral otázku Vzhled není "Jaké technologie podstatný a na doposud znáte?"... velikosti taky tˇech znám opravdu nezáleží. Duležité ˚ je velmi velmi mnoho to uvnitˇr ;) ... tímto :) Pˇredpokládal ale chci pochválit jsem tedy, že se pˇrehlednost jedná o technologie a šikovnou softwarového jednoduchost vývoje. To potom OdevSysu. nechápu, jestli to znamená, že je znám velmi podrobnˇe, anebo zda jsem o nich nˇekdy alesponˇ slyšel. Pro odpovˇed’ jsem byl donucen zvolit za hranici "nˇeco mezi"... no dobˇre, to už rýpu :) Pochavala za zcela jistˇe velmi ulehˇcenou práci pˇri odevzdávání domácích úkolu. ˚ pokraˇcování na další stranˇe ...



51





debata nad vysledkem validace

cervene bych psal jen chyby, ne informace

pokroˇcilý

pokroˇcilý

Máte nˇejaké pˇripomínky k OdevSysu, tomuto dotazníku nebo k pˇredmˇetu Algoritmizace? nevím proˇc nebyly už od zaˇcátku ty úlohy, které se mˇely povinne odevzdat zarámované tou cˇ ervenou farbou a naskoˇcilo to až teprve nˇekdy pˇred tydnem, protože já si stále myslel, že pro kombinovanou formu studia jsou tyhle úlohy nepovinné, když bylo od zaˇcátku nutno odevzdat jen ten první úkol, ten byl totiž zarámovanej cˇ ervenou Maximalni pocet bodu je 50, ziskal jse jich 80. Dalsi ulohy jsou bonus a nechtelo se mi je resit, protoze mam vice nez je maximum. Jak to, ze se mi prepocitaly body do semestru na 17.8 z maxima 20?



52

5.10 Závˇer testování Pˇribližnˇe 85% uživatelu˚ je mladší 30 let, 14% je v rozmezí 30 - 35 let a 1% je straší 35 let (viz kap. 5.8.3 „Dotazník“). Testující uživatelé byli podle svých znalostí a zkušeností rozdˇeleni do 3 skupin (viz tab. 5.6).


zaˇcáteˇcník

prumˇ ˚ erný

pokroˇcilý

31%

43%

26%

Tabulka 5.6: Procentuální rozdˇelení uživatelu˚ do skupin podle zkušeností. Po pˇridání textového pole s popisem, kde a jakým zpusobem ˚ získat pˇrihlašovací heslo, do prostˇredí s pˇrihlašovacím formuláˇrem nemˇeli žádní uživatelé problém s pˇrihlašováním. 34% uživatelu˚ zapomnˇelo pˇri prvním odevzdání doplnit do zdrojového kódu kontrolní rˇetˇezec. Bˇehem validace byli na tuto skuteˇcnost upozornˇeni a prumˇ ˚ ernˇe do 3 minut tuto chybu opravili a úlohu úspˇešnˇe odevzdali (viz kap. 5.9.2 „Odevzdání první úlohy“). 47% uživatelu˚ oznaˇcilo první odevzdání za "jednoduché", 53% za "mírnˇe obtížné"(viz kap. 5.9.4.1 „Odevzdání první úlohy“). Po diskusi s uživateli, která probˇehla po testovacím období, bylo zjištˇeno, že mnozí z nich pˇred prvním odevzdáním neˇcetli uživatelský manuál a vubec ˚ netušili o duležitosti ˚ pˇridání kontrolního rˇetˇezce. Dále se uživatelé zmínili, že jim v nápravˇe velmi pomohlo, když je validátor na tuto chybu upozornil. Pˇri odevzdávání dalších úloh se problém s chybˇejícím kontrolním rˇetˇezcem vyskytoval prumˇ ˚ ernˇe u 3% odevzdaných prací, z cˇ ehož lze usoudit, že se jednalo o opomenutí. Bˇehem testovacího období se vyskytly 3 vˇetší problémy, které znemožnovaly ˇ správný chod aplikace (nemožnost validovat nˇekteré úlohy, vypršení sezení na serveru a výpadek validátoru). Tyto komplikace byly po nˇekolika minutách od výskytu opraveny (viz kap. 5.9.3 „Odevzdání dalších úloh“). 69% uživatelu˚ si myslí, že není správné zveˇrejnovat ˇ testovací data (viz kap. 5.9.4.2 „Zverˇejnování ˇ testovacích dat“). Návrhy na zlepšení funkˇcnosti, vzhledu a ergonomie uživatelského rozhraní jsou uvedeny v kapitole 5.10.2 „Navrhované zmˇeny“. 5.10.1

Vyhodnocení hypotéz

H1: Pro uživatele je zpusob ˚ odevzdávání prací pˇres webové rozhraní pˇrínosný. Hypotéza je potvrzena. Hlavním pˇrínosem celého systému je zjednodušení procedur pro odevzdání, kontrolu a hodnocení prací. Cviˇcícímu uˇciteli je razantnˇe ušetˇren cˇ as, který strávil rˇešením tˇechto úkolu˚ a jeho jediným úkolem je navrhnout proceduru validace a zpusoby ˚ její kontroly. Studenti mají možnost okamžitého zjištˇení výsledku hodnocení odevzdané práce a také kdykoli zjistit svuj ˚ aktuální bodový stav. H2: Uživatelum ˚ neˇciní problém doplnit kontrolní rˇetˇezec do odevzdávané práce programovacího charakteru (zdrojový kód). Hypotéza je potvrzena. Viz kapitola 5.9.2 „Odevzdání první úlohy“ a kapitola 5.9.4.1 „Odevzdání první úlohy“.


53

H3: Uživatelé se bez problému˚ pˇrihlásí do webového rozhraní aplikace a odevzdávají práci intuitivnˇe a s jistotou. Hypotéza je potvrzena. Viz kapitola 5.9.1 „Pˇrihlášení do systému“ a kapitola 5.9.4.3 „Zmˇena vzhledu a pˇridání funkcí“. 5.10.2

Navrhované zmˇeny

Níže uvedené navrhované zmˇeny byly vybrány z uživatelských návrhu˚ na pˇridání funkcí, zmˇenu vzhledu a vylepšení ergonomie uživatelského rozhraní aplikace Odevzdávacího systému uvedených v kapitole 5.9.4.3 „Zmˇena vzhledu a pˇridání funkcí“. - zmˇena barvy rámeˇcku u odevzdaných úloh

souˇcasné barvy jsou nevýrazné a špatnˇe se zjišt’uje, zda je úloha korektnˇe odevzdaná

- zvˇetšení okna se zadáním úlohy

okno pro zadání úlohy je velmi malé a uživatelé jsou cˇ asto nuceni používat vertikální posuvník

- možnost znovu odevzdat úlohu, která již byla korektnˇe odevzdaná

uživatele napadne více rˇešení daného problému, ale má možnost vyzkoušet jen jedno

- možnost odeslat více souboru˚ najednou

složitˇejší úlohy jsou cˇ asto rozmístˇeny do více souboru, ˚ ale je možné odevzdat jen jeden

- v pˇrehledu odevzdaných úloh pˇridat možnost filtrování obsahu - úspˇešnˇe odevzdané, neúspˇešnˇe odevzdané, všechny úlohy

jeden seznam s úspˇešnˇe i neúspˇešnˇe odevzdanými úlohami není pˇríliš pˇrehledný

- na úvodní stránku pˇridat seznam s úlohami, které je nutné odevzdat

uživatelé musejí postupnˇe procházet všechny množiny úloh a kontrolovat, zda v nˇekteré není neodevzdaná úloha

- jsou-li všechny úlohy z množiny úloh úspˇešnˇe odevzdané, mˇela by se množina oznaˇcit napˇríklad „fajfkou“

uživatelé musejí projít všechny úlohy v množinˇe a zjišt’ovat zda jsou korektnˇe odevzdané

- dynamická zmˇena bodu˚ v zadání úlohy

poˇcet bodu˚ za úspˇešné odevzdání úlohy se každý týden zmenší o polovinu, uživatelé musejí poˇcítat poˇcet bodu˚ a dny od otevˇrení úlohy,

- oznámení o pˇridání nové úlohy emailem

v souˇcasné dobˇe zjistí uživatelé pˇridání nové úlohy až po pˇrihlášení do systému

- vytvoˇrení tabulky top nejlepších rˇešení pro každou úlohu, tabulku s nejrychlejšími rˇešiteli a tím z odevzdávání každé úlohy udˇelat soutˇež

ˇ ˇ A NÁMETY ˇ KAPITOLA 6. ZÁVER POKRACOVÁNÍ PRÁCE

54

6 Závˇer a námˇety pokraˇcování práce Tato práce byla zamˇerˇena na tvorbu softwarového rozhraní webové aplikace pro odevzdávání studentských prací. Byla umožnˇena kontrola funkˇcní správnosti odevzdaného zdrojového kódu za pomoci externího validátoru dodaného Západoˇceskou univerzitou v Plzni. ˇ Dodaný validátor se povedlo modifikovat pro potˇreby Fakulty elektrotechnické Ceského vysokého uˇcení technického v Praze. Zejména byla zrušena povinnost pˇridávat k názvu souboru prefix identifikující úlohu. Bylo umožnˇeno souˇcasnˇe odevzdávat více souboru˚ urˇcených k validaci. Namísto vytváˇrení souboru˚ na pevném disku bylo zprostˇredkováno ukládání dat do databáze. Souˇcástí systému je modul urˇcený k vyhledávání duplicitních zdrojových kódu˚ mezi odevzdanými pracemi. Vyhledávání je realizováno na tˇrech nastavitelných úrovních, které se liší dukladností ˚ hledání a cˇ asovou nároˇcností. Systém umožnuje ˇ odevzdání práce z více pˇredmˇetu. ˚ Dále také zobrazení studentu˚ registrovaných do systému podle jejich pˇredmˇetu, studijních skupin a paralelky. Tomu byla podˇrízena definice rolí jednotlivých uživatelu, ˚ aby nebyla porušena ochrana osobních údaju. ˚ Dále byl umožnˇen hromadný import uživatelu˚ z pˇredem definovaného XML souboru. Obsah souboru je definován pomocí novˇe vytvoˇreného znaˇckovacího jazyka, který zjednodušuje import dat ze souboru do prostˇredí aplikace. Díky jednoduchosti rozšíˇrení o jazykové mutace a díky zvolené technologii Java, nic nebrání nasazení systému v ruzných ˚ zemích a na ruzných ˚ platformách. V souˇcasné dobˇe je podporována cˇ eská a anglická mutace. Aplikace byla testována v rámci pˇredmˇetu Algoritmizace vyuˇcovaného na Fakultˇe elekˇ trotechnické Ceského vysokého uˇcení technického v Praze. Bˇehem testování se samotný systém choval podle oˇcekávání a nebyly zjištˇeny žádné nedostatky. Výstupem testování byly uživatelské návrhy na pˇridání nových funkcí, zmˇenu vzhledu a vylepšení ergonomie, z nichž byla vˇetšina realizována. Hlavním pˇrínosem celého systému je zjednodušení procedur pro odevzdání, kontrolu a hodnocení prací. Cviˇcícímu uˇciteli je výraznˇe ušetˇren cˇ as, který trávil rˇešením tˇechto úkolu. ˚ Nyní je jeho jediným úkolem navrhnout proceduru validace a zpusoby ˚ její kontroly. Studenti mají možnost okamžitého zjištˇení výsledku hodnocení odevzdané práce a také kdykoli zjistit svuj ˚ aktuální bodový stav. Námˇetu˚ na pokraˇcování práce je mnoho. Vyhledávání duplicitních prací by mohlo probíhat v pravidelném cˇ asovém intervalu na pozadí aplikace. Pˇri velkém poˇctu odevzdaných prací by se výraznˇe snížila doba cˇ ekání na výsledky. Dalším významným rozšíˇrením by mohlo být vytvoˇrení plug-inu pro vývojové prostˇredí (napˇr. NetBeans IDE), který by vzdálenˇe komunikoval s Odevzdávacím systémem a umožnil pˇrímé zaslání zdrojových kódu˚ urˇcených k validaci.

KAPITOLA 7. LITERATURA

55

7 Literatura [1] Java EE at a Glance [online]. Ver. 5. Santa Clara (California) : Sun Microsystems, 2006-06-22 [cit. 2009-05-01]. URL: . [2] Java SE at a Glance [online]. Ver. 6. Santa Clara (California) : Sun Microsystems, 2008-08-12 [cit. 2009-05-01]. URL: . [3] Java Servlet Technology [online]. Ver. 2.5. Santa Clara (California) : Sun Microsystems, 200308-25 [cit. 2009-05-01]. URL: . [4] Design Patterns: Model-View-Controller [online]. Santa Clara (California) : Sun Microsystems, c2002, 2007-12-18 [cit. 2009-05-01]. URL: . [5] SpringSource.org [online]. Ver. 2.5.6. SpringSource, c2009, [cit. 2009-05-01]. URL: . [6] Enterprise JavaBeans Technology [online]. Ver. 3.0. Santa Clara (California) : Sun Microsystems, 2006-07-11 [cit. 2009-05-01]. URL: . [7] Java Persistence API [online]. Santa Clara (California) : Sun Microsystems, 2006-05-01 [cit. 2009-05-01]. URL: . [8] Hibernate [online]. Ver. 3.3.1. Raleigh (North Carolina) : Red Hat, c2009, [cit. 2009-05-01]. URL: . [9] JavaServer Pages Technology [online]. Ver. 2.1. Santa Clara (California) : Sun Microsystems, 2005-05-11 [cit. 2009-05-01]. URL: . [10] Active Server Pages [online]. Ver. 3.0. Redmond (Washington) : Microsoft Corporation, c2009, [cit. 2009-05-01]. URL: . [11] PHP: Hypertext Preprocessor [online]. Ver. 5.2.9. The PHP Group, 2009-04-14 [cit. 2009-0501]. URL: . [12] HALL M.: Java Servlety a stránky JSP. 1. vyd. Praha : Neocortex, 2001. 586 s. ISBN 8086330-06-0. [13] JavaServer Faces Technology [online]. Ver. 1.2. Santa Clara (California) : Sun Microsystems, c1994-2009, 2006-08-23 [cit. 2009-05-01]. URL: . [14] Hightower R.: JSF for nonbelievers: The JSF application lifecycle [online]. Armonk (New York) : IBM, 01 Mar 2005 [cit. 2009-05-01]. URL: . [15] JavaBeans Technology [online]. Santa Clara (California) : Sun Microsystems, 2008-09-02 [cit. 2009-05-01]. URL: . [16] MANN K. D.: JavaServer Faces in Action. 1st printing. London: Manning Publications, 2004. 1038s. ISBN 1-932394-11-7.

KAPITOLA 7. LITERATURA

56

[17] Open Source Ajax, J2EE Ajax, JSF Java Framework [online]. Ver. 1.8.0. Calgary (Canada) : ICEsoft Technologies, 2008-04-02 [cit. 2009-05-01]. URL: . [18] Asynchronous JavaScript + XML [online]. Mountain View (California) : Mozilla Organization, last modified 12:55, 29 Apr 2009 [cit. 2009-05-01]. URL: . [19] Rich Internet application [online]. St. Petersburg (Florida) : Wikimedia Foundation, 2005, last modified on 13 May 2009, at 11:20 (UTC) [cit. 2009-05-01]. URL: . [20] JavaScript [online]. Ver. 1.8.1. Mountain View (California) : Mozilla Organization, last modified 20:07, 30 Apr 2009 [cit. 2009-05-01]. URL: . [21] Entity Lifecycle Management [online]. Ver. 4.2.0. Redwood Shores (California) : Oracle Corporation, c2008, 2009-04-14 [cit. 2009-05-01]. URL: . [22] MySQL [online]. Ver. 5.1. Santa Clara (California) : Sun Microsystems, 2009-04-02 [cit. 2009-05-01]. URL: . [23] API Specifications for Java Platform Enterprise Edition [online]. Ver. 5.0. Santa Clara (California) : Sun Microsystems, c2007, 2008-02-12 [cit. 2009-05-01]. URL: . [24] API Specifications for Java Platform Standard Edition [online]. Ver. 6.0. Santa Clara (California) : Sun Microsystems, c2008, 2008-09-16 [cit. 2009-05-01]. URL: . ˇ v Plzni, 2007 [cit. 2009-05-01] [25] Valenta L.: Validaˇcní server. [CD-ROM]. Plzenˇ : ZCU [26] Lesson: Regular Expressions [online]. Santa Clara (California) : Sun Microsystems, Last Updated 2/14/2008 [cit. 2009-05-01]. URL: . [27] Ostermiller S.: Finding Comments in Source Code Using Regular Expressions. c1996-2008, [cit. 2009-05-01]. URL: . [28] Žáˇcek K.: Úvod do skriptování v BASH. Ver. 1.4. KZ SoftWorks, c2000, [cit. 2009-05-01]. URL: . [29] Java Internationalization [online]. Santa Clara (California) : Sun Microsystems, 2008-08-12 [cit. 2009-05-01]. URL: .

ˇ PRÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

57

A Seznam použitých zkratek AJAX Asynchronous Javascript And XML - technologie umožnující ˇ interaktivní zmˇenu cˇ ástí webové stránky bez nutnosti znovunaˇctení celé stránky stránek API Application Programming Interface - sbírka metod cˇ i tˇríd, které muže ˚ programátor využívat pro vývoj aplikací ASP Active Server Pages - skriptovací platforma spoleˇcnosti Microsoft Corporation, primárnˇe urˇcená pro dynamické zpracování webových stránek na stranˇe serveru DOM Document Object Model - API umožnující ˇ pˇrístup cˇ i modifikaci obsahu a struktury dokumentu GUI Graphical User Interface - druh komunikace s poˇcítaˇcem mající podobu interaktivních grafických prvku˚ HTML HyperText Markup Language - znaˇckovací jazyk urˇcený pro tvorbu hypertextových dokumentu˚ JAR Java Archive - platformˇe nezávislý formát pro archivaci souboru˚ JDBC Java DataBase Connectivity - registrovaná ochranná známka spoleˇcnosti Sun Microsystems, Inc. Puvodní ˚ význam je API pro programovací jazyk Java, které definuje jednotné rozhraní pro pˇrístup k relaˇcním databázím. JDK Java Development Kit - množina základních nástroju˚ pro vývoj aplikací na platformˇe Java. JSF JavaServer Faces - webový framework postavený na programovacím jazyce Java, urˇcený pro vývoj profesionálních webových aplikací JSP JaveServer Pages - technologie pro psaní dynamických XHTML stránek založená na jazyce Java JVM Java Virtual Machine - abstraktní poˇcítaˇc, který obsahuje runtime system (realizuje spojení s hardwarem) a interpreter (vykonává binární kód) MVC Model View Controller - softwarová architektura, která rozdˇeluje datový model aplikace, uživatelské rozhraní a rˇídicí logiku do tˇrí nezávislých komponent tak, že modifikace nˇekteré z nich má minimální vliv na ostatní ORM Object-Relational Mapping - programovací technika pro konverzi dat mezi relaˇcními databázemi a objektovˇe orientovanými programovacími jazyky PDA Personal Digital Assistant - malý kapesní poˇcítaˇc, ovládaný obvykle dotykovou obrazovkou a perem PHP Hypertext Preprocessor - multiplatformní skriptovací programovací jazyk, urˇcený pro tvorbu dynamických webových stránek RIA Rich Internet Application - smˇer, který se snaží pˇreklenout rozdíly mezi klasickou webovou a desktopovou aplikací RMI Remote Method Invocation - rozhraní umožnující ˇ objektu z jednoho virtuálního stroje (JVM) volat metody jiného objektu z jiného virtuálního stroje

ˇ PRÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

58

RSA Rivest, Shamir, Adleman - šifra s veˇrejným klíˇcem, který je vhodný pro podepisování a šifrování SQL Structured Query Language - standardizovaný dotazovací jazyk používaný pro práci s daty v relaˇcních databázích SSH Secure Shell - zabezpeˇcený komunikaˇcní protokol pro poˇcítaˇcové sítˇe používající TCP/IP TCP/IP Transmission Control Protocol/Internet Protocol - rodina protokolu˚ pro komunikaci v poˇcítaˇcové síti TLD Tag Library Descriptor - XML dokument popisující znaˇcky pˇríslušné knihovny, jejich atributy a vztahy mezi nimy URI Uniform Resource Identifier - rˇetˇezec znaku˚ s definovanou strukturou, který slouží k pˇresné specifikaci zdroje informací, hlavnˇe za úˇcelem jejich použití pomocí poˇcítaˇcové sítˇe W3C World Wide Web Consortium - mezinárodní konsorcium dohlížející na vývoj internetových standardu˚ XHTML eXtensible HyperText Markup Language - znaˇckovací jazyk urˇcený pro tvorbu hypertextových dokumentu˚ XML eXtensible Markup Language - jazyk umožnující ˇ popsat strukturu dokumentu z hlediska vˇecného obsahu jednotlivých cˇ ástí

ˇ PRÍLOHA B. UŽIVATELSKÝ MANUÁL

59

B Uživatelský manuál B.1

Pˇrihlášení do systému

Po zadání adresy Odevzdávacího systému do internetového prohlížeˇce, se na úvodní obrazovce zobrazí pˇrihlašovací formuláˇr (obr. B.1). Každý uživatel v nˇem musí vyplnit své uživatelské jméno a heslo a poté z nabídky pˇredmˇetu˚ vybrat ten, do kterého je zapsán. Po zadání korektních údaju˚ a stisknutí tlaˇcítka Pˇrihlásit je pˇrihlášen do systému. Pokud je pˇrihlašovací jméno nebo heslo chybné, pˇrípadnˇe je zvolen pˇredmˇet, do kterého není uživatel zapsán, zobrazí se varovné hlášení.

Obrázek B.1: Formuláˇr pro pˇrihlášení do systému.

Obrázek B.2: Prostˇredí po pˇrihlášení do systému.


B.2

60

Prostˇredí po pˇrihlášení

Po pˇrihlášení do systému je zobrazena úvodní stránka popisující základní kroky pro odevzdání práce (obr. B.2). V záhlaví stránky je umístˇeno záložkové menu, které je pˇrístupné ze všech stránek aplikace a jeho položky mají následující význam: Domu˚ - úvodní stránka s informacemi o systému, Odevzdání práce - seznam úloh s formuláˇrem pro odevzdání práce (viz kap. B.3 „Odevzdání práce“), Kontrola prací - seznam všech odevzdaných prací (viz kap. B.4 „Kontrola odevzdaných prací“), Uživatelská nastavení - nastavení informací o uživateli (viz kap. B.5 „Zmˇena uživatelských nastavení“).

B.3

Odevzdání práce

Na stránce Odevzdání práce je zobrazen seznam množin úloh (obr. B.3) a jejich vlastnosti: název - název množiny úloh, max. bodu˚ v množinˇe - maximální poˇcet bodu, ˚ který je možné získat za odevzdání úloh v množinˇe, musí být odevzdáno - udává zda v množinˇe musejí být odevzdány všechny úlohy, žádné úlohy nebo zadavatelem vybrané úlohy, otevˇrení - termín otevˇrení (pˇred tímto cˇ asovým údajem není možné množinu otevˇrít), uzavˇrení - termín uzavˇrení (po tomto cˇ asovém údaji není možné množinu otevˇrít).

Obrázek B.3: Výbˇer množiny úloh. Po otevˇrení jedné z množin je zobrazen záložkový seznam úloh k odevzdání (obr. B.4), kde je u každé úlohy uveden maximální poˇcet bodu, ˚ který je možné získat, od kdy do kdy je možné úlohu odevzdat, zadání úlohy a formuláˇr pro odeslání souboru s rˇešením. Stisknutí tlaˇcítka Procházet vyvolá nabídku se seznamem souboru˚ na pevném disku. Po výbˇeru požadovaného souboru a následném stisknutí tlaˇcítka Upload je soubor nakopírován na validaˇcní server. Tímto zpusobem ˚ je možné opakovanˇe pˇrenést vˇetší množství souboru. ˚ Jejich typ a velikost je omezena nastavením od zadavatele úlohy. Po bezchybném pˇrenosu se hlavní atributy souboru zobrazí v tabulce pod zasílacím formuláˇrem. Pomocí odkazu Odebrat, který je u každé položky v tabulce, je možné pˇrenesený soubor odstranit. Po stisknutí tlaˇcítka


61

Odeslat úlohu je soubor uložen do databáze a v pˇrípadˇe zdrojového kódu je spuštˇena validaˇcní procedura. O výsledku validace je uživatel bˇehem pár vteˇrin informován zobrazením dialogového okna.

Obrázek B.4: Výbˇer úlohy.


B.4

62

Kontrola odevzdaných prací

Položka v menu Kontrola prací pˇresmˇeruje zobrazení na stránku se všemi odevzdanými pracemi (obr. B.5). U každé práce je uveden název úlohy, datum a cˇ as odevzdání, seznam odevzdaných souboru, ˚ poˇcet bodu˚ získaných za úlohu, výsledek validace s odkazem na detailní popis a pˇrípadné hodnocení od zadavatele úlohy. V horní cˇ ásti stránky je uveden celkový poˇcet bodu, ˚ který uživatel získal za všechny odevzdané úlohy.

Obrázek B.5: Kontrola odevzdaných prací.

B.5

Zmˇena uživatelského nastavení

V cˇ ásti Uživatelské nastavení (obr. B.6) má každý možnost zmˇenit pˇrístupové heslo, kontaktní email a jazyk systému.

Obrázek B.6: Zmˇena uživatelského nastavení.

ˇ PRÍLOHA C. ADMINISTRÁTORSKÝ MANUÁL

63

C Administrátorský manuál C.1 Pˇrihlášení do systému V prubˇ ˚ ehu instalace odevzdávacího systému je vytvoˇren pomocný pˇredmˇet s název „Nastavení systému“. Tento pˇredmˇet slouží k prvotnímu pˇrihlášení uživatele s rolí Super uživatel a k nastavení systému (viz kap. C.2 „Nastavení systému“). Po konfiguraci systému a vytvoˇrení nového pˇredmˇetu a uživatelu˚ se po zadání adresy Odevzdávacího systému do internetového prohlížeˇce zobrazí pˇrihlašovací formuláˇr s nabídkou vytvoˇrených pˇredmˇetu˚ (obr. C.1). Každý uživatel v nˇem musí vyplnit své uživatelské jméno a heslo a poté z nabídky pˇredmˇetu˚ vybrat ten, do kterého je zapsán. Uživatel s rolí Super Uživatel se muže ˚ bez omezení pˇrihlásit do jakéhokoli pˇredmˇetu. Po zadání korektních údaju˚ a stisknutí tlaˇcítka Pˇrihlásit je pˇrihlášen do systému. Pokud je pˇrihlašovací jméno nebo heslo chybné, pˇrípadnˇe je zvolen pˇredmˇet, do kterého není uživatel zapsán, zobrazí se varovné hlášení.

Obrázek C.1: Formuláˇr pro pˇrihlášení do systému.

C.2 Nastavení systému Toto nastavení je pˇrístupné pouze uživateli s rolí Super uživatel. Pˇred bˇežným používáním Odevzdávacího systému je nutné provést jeho prvotní konfiguraci. Ta je provádˇena v cˇ ásti Nastavení systému umístˇené v menu na záložce Administrace. Zobrazený formuláˇr (obr. C.2) umožnuje ˇ nastavení data prvního dne semestru a relativní cestu k validaˇcní službˇe. Datum prvního dne semestru je nutné nastavit pro správné urˇcení otevˇrení a uzavˇrení množiny úloh (viz kap. C.4 „Vytvoˇrení nové množiny úloh“). Cesta k validaˇcní službˇe je nezbytná pro umožnˇení kontroly odevzdaných zdrojových kódu. ˚

Obrázek C.2: Nastavení systému.


64

C.3 Vytvoˇrení nového pˇredmˇetu Toto nastavení je pˇrístupné jen uživateli s rolí Super uživatel. Pˇred bˇežným používáním Odevzdávacího systému je nutné, aby systém registroval alesponˇ jeden pˇredmˇet. Ten je možné vytvoˇrit v cˇ ásti Vytvoˇrit nový pˇredmˇet umístˇené v menu pod položkou Administrace. Zobrazený formuláˇr (obr. C.3) umožnuje ˇ definovat název, kód a semestr, ve kterém je pˇredmˇet vyuˇcován. Kód pˇredmˇetu musí být v rámci celého systému jedineˇcný. Je-li zadán kód, který už v systému existuje, uživatel je okamžitˇe upozornˇen. Položka vyuˇcovaný semestr umožnuje ˇ vybrat zimní, letní a zimní i letní.

Obrázek C.3: Vytvoˇrení nového pˇredmˇetu.

C.4 Vytvoˇrení nové množiny úloh Vˇetšina zadaných úloh muže ˚ mít nˇekteré spoleˇcné vlastnosti jako napˇr. od kdy do kdy muže ˚ být odevzdána, maximální poˇcet bodu, ˚ povolený typ odevzdávaného souboru, apod. Aby se tyto vlastnosti nemusely nastavovat pro každou úlohu zvlášt’, umožnuje ˇ systém vytvoˇrit tzv. množinu úloh, která definuje vlastnosti pro všechny úlohy v ní umístˇené. Vytvoˇrení nové množiny úloh je možné po kliknutí na položku Vytvoˇrit novou množinu v cˇ ásti menu Administrace. Zobrazený formuláˇr (obr. C.4) se skládá ze dvou hlavních cˇ ástí. První cˇ ást, od shora až po Upˇresnující ˇ nastavení úlohy, je urˇcena pro nastavení vlastností celé množiny. Zbylá cˇ ást formuláˇre je urˇcena pro upˇresnující ˇ nastavení úlohy. Položka Upˇresnující ˇ nastavení pro muže ˚ nabývat dvou stavu: ˚ všechny úlohy v množinˇe (spoleˇcné) - upˇresnující ˇ nastavení je definováno v rámci množiny a použito na všechny úlohy v množinˇe, každou úlohu zvlášt’ (oddˇelené) - upˇresnující ˇ nastavení je definováno v prubˇ ˚ ehu vytváˇrení nové úlohy a to pro každou úlohu zvlášt’. Nastavení ostatních vlastností je velice intuitivní.


65

Obrázek C.4: Vytvoˇrení nové množiny úloh.

C.5 Vytvoˇrení nové úlohy Po kliknutí na položku Vytvoˇrit novou úlohu v cˇ ásti menu Administrace je zobrazen formuláˇr umožnující ˇ vytvoˇrení nové úlohy (obr. C.5). Každá úloha je souˇcástí tzv. množiny úloh, která definuje její základní vlastnosti (od kdy do kdy je možné úlohu odevzdat apod.), ale také muže ˚ urˇcovat další její upˇresnující ˇ vlastnosti (viz kap. C.4 „Vytvoˇrení nové množiny úloh“). Na obrázku C.5 je vytváˇrena úloha, která bude souˇcástí množiny První sada úloh. V nastavení této množiny je povolena možnost upˇresnit nastavení úlohy pro každou úlohu zvlášt’, proto je možné v cˇ ásti Upˇresnující ˇ nastavení úlohy mˇenit jednotlivé vlastnosti. V opaˇcném pˇrípadˇe, pokud by v množinˇe bylo upˇresnující ˇ nastavení definováno pro všechny úlohy spoleˇcnˇe, by vlastnosti v cˇ ásti Upˇresnující ˇ nastavení úlohy byly needitovatelné. Pokud je vytváˇrená úloha programovacího charakteru a zadavatel bude chtít ovˇerˇit její správnost pomocí validátoru, je nutné vytvoˇrit vzorové rˇešení a definovat kontrolní data pomocí kterých bude odevzdaná úloha validovaná. Pˇrekopírování vzorových souboru˚ a definice kontrolních dat je provádˇena prostˇrednictvím formuláˇre Nastavení validaˇcní úlohy (obr. C.6). Stisknutí tlaˇcítka Procházet vyvolá nabídku se seznamem souboru˚ na pevném disku. Po výbˇeru požadovaného souboru a následném stisknutí tlaˇcítka Upload je soubor nakopírován na validaˇcní server. Tímto zpusobem ˚ je možné opakovanˇe pˇrenést vˇetší množství souboru. ˚ Po bezchybném pˇrenosu se hlavní atributy souboru zobrazí v tabulce pod zasílacím for-


66

Obrázek C.5: Vytvoˇrení nové úlohy.

muláˇrem. Pomocí odkazu Odebrat, který je u každé položky v tabulce, je možné pˇrenesený soubor odstranit. Kontrolní vstupní data mohou být definována ruˇcnˇe, kdy je možné zadat neomezený poˇcet kontrolních vstupu, ˚ ale souˇcasnˇe mohou být i automaticky generována. Je-li zvolena možnost generování vstupních dat, je pˇred testováním každé úlohy vytvoˇrena množina 20 testovacích rˇetˇezcu˚ o velikosti 500 cˇ íselných hodnot.


67

Obrázek C.6: Vytvoˇrení nové validaˇcní úlohy.

C.6 Agenda uživatelu˚ Po kliknutí na položku Agenda uživatelu˚ v cˇ ásti menu Administrace jsou zobrazeny formuláˇre pro hromadný import uživatelu˚ (obr. C.7) a pro vytvoˇrení nového uživatele (obr. C.8). Hromadný import uživatelu˚ je umožnˇen z pˇredem definovaného XML souboru, jehož struktura a popis jednotlivých znaˇcek jsou uvedeny níže. Pˇrihlašovací jméno musí být v rámci celého systému jedineˇcné. import - uvnitˇr jsou jednotliví uživatelé, každý oznaˇcen znaˇckou user (povinné) user - uvnitˇr jsou atributy jednoho uživatele (povinné) nickname - pˇrihlašovací jméno (povinné) password - pˇrihlašovací heslo right - uživatelská role (user, teacher, admin) (povinné) firstname - jméno (povinné) lastname - pˇríjmení (povinné) email - email (povinné) locale - preferovaný jazyk systému (cs, en) subjects - uvnitˇr jsou jednotlivé pˇredmˇety, každý oznaˇcen znaˇckou subject subject - kód pˇredmˇetu (povinné) classes - uvnitˇr jsou jednotlivé tˇrídy, každá oznaˇcena znaˇckou class (povinné jen pokud znaˇcka right obsahuje atribut user nebo teacher) class - uvnitˇr jsou atributy jedné tˇrídy (povinné, je-li uvedena znaˇcka classes) number - cˇ íslo cviˇcící skupiny (povinné, je-li uvedena znaˇcka classes) group - cˇ íslo paralelky (povinné, je-li uvedena znaˇcka classes)


68

Není-li vyplnˇena znaˇcka password, bude v pˇrípadˇe použití systému pro Fakultu elektrotechˇ nickou Ceského vysokého uˇcení technického v Praze použit pro autentizaci uživatelu˚ interní ovˇerˇovací systém. Pomocí XML souboru nelze z duvodu ˚ bezpeˇcnosti importovat uživatele typu Super uživatel. Pˇri nevyplnˇení znaˇcky locale je uživateli nastaven výchozí jazyk cˇ eština. Níže uvedený fragment XML souboru vytvoˇrí po naˇctení do systému nového uživatele Karla Vomáˇcku. ... <user> vomacka <password>heslo teacher Karel cka Vomáˇ <email>[email protected] cs <subjects> <subject>Y36PJV 101 1 102 1 ...

Obrázek C.7: Import uživatelu. ˚


69

Formuláˇr Vytvoˇrení nového uživatele (obr. C.8) umožnuje ˇ také vytvoˇrení nové cviˇcící skupiny. Oprávnˇení pro nového uživatele je možné pˇridˇelit v závislosti na roli pˇrihlášeného uživatele: uˇcitel - má oprávnˇení vytvoˇrit uživatele typu student, administrátor - má oprávnˇení vytvoˇrit uživatele typu student a uˇcitel, super uživatel - má oprávnˇení vytvoˇrit uživatele jakéhokoli typu.

Obrázek C.8: Vytvoˇrení nového uživatele

C.7 Datové seznamy a editace záznamu˚ V cˇ ásti menu Seznamy jsou pod jednotlivými položkami umístˇeny seznamy všech vytvoˇrených pˇredmˇetu, ˚ cviˇcících skupin, množin úloh, úloh a uživatelu. ˚ V této cˇ ásti aplikace je možné editovat veškeré záznamy vytvoˇrených objektu, ˚ pˇrípadnˇe objekt odstranit. Pro editaci objektu staˇcí u vybrané položky stisknout tlaˇcítko Editovat a zobrazí se dialogové okno s jednotlivými vlastnostmi (viz editace pˇredmˇetu na obr. C.9). Po kliknutí na tlaˇcítko odstranit je uživatel upozornˇen, zda chce vybraný objekt opravdu vymazat. Pokud operaci potvrdí, odstraní se spoleˇcnˇe s vybraným objektem i všechny objekty, které spadají do jeho hierarchie a nemají vztah k jinému objektu v systému. Je-li napˇríklad odstranˇen pˇredmˇet, jsou spolu s ním vymazány: množiny úloh - všechny množiny úloh v pˇredmˇetu, které nejsou souˇcástí jiného pˇredmˇetu, úlohy - všechny úlohy, které jsou souˇcástí odstranˇených množin, odevzdané úlohy - všechny odevzdané úlohy typu odstranˇených úloh, cviˇcící skupiny - všechny cviˇcící skupiny a paralelky pˇredmˇetu, uživatelé - všichni uživatelé pˇredmˇetu, kteˇrí nejsou cˇ leny jiného pˇredmˇetu.


70

Obrázek C.9: Editace záznamu˚ vytvoˇreného pˇredmˇetu.

C.8 Kontrola odevzdaných prací Položka v menu Kontrola prací pˇresmˇeruje zobrazení na stránku se všemi uživateli pˇredmˇetu (obr. C.10). Jednotlivé položky zobrazeného seznamu je možné filtrovat podle cviˇcící skupiny a podle poˇcáteˇcního písmene pˇríjmení uživatele. Po vybrání uživatele je zobrazen seznam všech jeho odevzdaných prací. U každé práce je uveden název úlohy, datum a cˇ as odevzdání, seznam odevzdaných souboru, ˚ poˇcet bodu˚ získaných za úlohu, výsledek validace s odkazem na detailní popis a možnost doplnit dodateˇcné hodnocení nebo textovou poznámku.


71

Obrázek C.10: Kontrola odevzdaných prací.

C.9 Vyhledávání duplicitních prací Stránka pro vyhledávání duplicitních prací (obr. C.11) je umístˇena pod položkou Vyhledávání duplicitních prací v cˇ ásti menu Administrace. V pravé cˇ ásti je zobrazen poˇcet všech odevzdaných prací a v levé cˇ ásti je umožnˇen výbˇer úrovnˇe hledání. Systém nabízí tˇri úrovnˇe: 1. úrovenˇ - vyhledávání znak po znaku, 2. úrovenˇ - vyhledávání bez komentáˇru, ˚ bílých znaku, ˚ názvu tˇríd a metod, package a import, 3. úrovenˇ - 2. úrovenˇ + odstranˇení názvu identifikátoru˚ a porovnání poˇradí klíˇcových slov (int, while, for, atd.).

Obrázek C.11: Vyhledávání duplicitních prací.

ˇ ˇ PRÍLOHA D. OBSAH PRILOŽENÉHO CD

D Obsah pˇriloženého CD ./ - koˇrenový adresáˇr archive/ - adresáˇr obsahující archivy všech cˇ ástí diplomové práce - doc.zip - archiv s dokumentacemi zdrojových kódu˚ (javadoc) - odevsys.zip - archiv se zdrojovým kódem Odevzdávacího systému - thesis.zip - archiv s textem diplomové práce ve formátech PDF a PS - validator.zip - archiv se soubory validaˇcního serveru doc/ - adresáˇr obsahující dokumentace zdrojových kódu˚ (javadoc) - odevsys - dokumentace zdrojového kódu k Odevzdávacímu systému - validator - dokumentace zdrojového kódu k validaˇcnímu serveru source/ - adresáˇr obsahující zdrojový kód Odevzdávacího systému thesis/ - adresáˇr obsahující text diplomové práce - odevsys.pdf - text diplomové práce ve formátu PDF - odevsys.ps - text diplomové práce ve formátu PS validator/ - adresáˇr obsahující soubory validaˇcního serveru - client - klientská cˇ ást - doc - dokumentace - program - validaˇcní server

72

Systém pro odevzdávání studentských prací. Bc. Radek Malinský

Recommend Documents