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

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů 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četní technika květen 2009

2 Poděkování Velmi rád bych poděkoval a vyslovil uznání všem, kteří se podíleli na vzniku této práce. Především vedoucímu diplomové práce Ing. Miroslavu Balíkovi, Ph.D., za trpělivost a pevné nervy při vedení a poskytování praktických rad. Dále bych rád poděkoval mé rodině a přátelům, kteří mě podporovali a neustále přicházeli s novými nápady na zlepšení. ii

3 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne iii

4 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í část popisuje návrh a realizaci aplikace za pomoci technologií Java EE. Především se věnuje vytvoření relačního databázového schématu z objektového modelu. Další část je zaměřena na použití validátoru zdrojových kódů, který mimo syntaktických a sémantických pravidel kontroluje také funkční správnost kódu. Poslední část uvádí návrh a realizaci modulu pro vyhledávání duplicitních prací mezi odevzdanými zdrojovými kódy. iv

5 Obsah Seznam obrázků Seznam tabulek viii ix 1 Úvod Důvody vzniku systému Popis problému, specifikace cíle Popis řešeného problému Vymezení cílů Analýza a návrh řešení Výběr implementačního prostředí Java Enterprise Edition Prezentační vrstva Aplikační vrstva Vrstva persistence dat JavaServer Pages Skriptovací značky Knihovny značek JavaServer Faces Životní cyklus JSF Navigace v JSF Java Beans Java Beans a JSF ICEfaces ICEfaces architektura Hibernate Java Persistence API Anotace Entity Manager a práce s objekty Životní cyklus entity Modul vyhledávání duplicitních prací Popis modulu Princip funkce Modul importování uživatelů Popis modulu Uživatelské role Role Student Role Učitel Role Administrátor Role Super uživatel XML šablona Validátor zdrojových kódů Popis validátoru Princip funkce validátoru Konfigurace validačního serveru Konfigurace domény v

6 4 Realizace Návrh databáze Konfigurace JPA Vytvoření entity Modul vyhledávání duplicitních prací Realizace 1. úrovně vyhledávání Realizace 2. úrovně vyhledávání Odstranění komentářů Odstranění ostatních vlastností Realizace 3. úrovně vyhledávání Modul importování uživatelů Čtení XML šablony Validátor zdrojových kódů Zaslání souborů k validaci Uživatelské rozhraní Autentizace uživatele Autentizační skript Spuštění autentizačního skriptu Lokalizace do více jazyků Testování Cíl testování Hypotézy Příprava na testování Harmonogram testování Získání zpětné vazby Skupina testujících uživatelů Požadované profily testujících osob Skutečné profily testujících osob Závěrečný dotazník První část dotazníku Účel sledování otázek v první části dotazníku Druhá část dotazníku Účel sledování otázek ve druhé části dotazníku Dělení uživatelů do skupin Průběh testu Seznámení uživatelů s aplikací Testování aplikace Dotazník Výsledky testu Přihlášení do systému Odevzdání první úlohy Odevzdání dalších úloh Dotazník Odevzdání první úlohy Zveřejňování testovacích dat Změna vzhledu a přidání funkcí Závěr testování Vyhodnocení hypotéz Navrhované změny vi

7 6 Závěr a náměty pokračování práce 54 7 Literatura 55 A Seznam použitých zkratek 57 B Uživatelský manuál 59 B.1 Přihlášení do systému B.2 Prostředí po přihlášení B.3 Odevzdání práce B.4 Kontrola odevzdaných prací B.5 Změna uživatelského nastavení C Administrátorský manuál 63 C.1 Přihlášení do systému C.2 Nastavení systému C.3 Vytvoření nového předmětu C.4 Vytvoření nové množiny úloh C.5 Vytvoření nové úlohy C.6 Agenda uživatelů C.7 Datové seznamy a editace záznamů C.8 Kontrola odevzdaných prací C.9 Vyhledávání duplicitních prací D Obsah přiloženého CD 72 vii

8 Seznam obrázků 3.1 Životní cyklus zpracování událostí v JSF ICEfaces architektura Životní cyklus entity Proces validace zdrojového kódu Informace o způsobu získání hesla pro přihlášení Chybné a úspěšné odevzdání první úlohy Rozdělení do skupin podle věku uživatelů Četnost odpovědí na 2. otázku z II. dotazníku Četnost odpovědí na 3. otázku z II. dotazníku B.1 Formulář pro přihlášení do systému B.2 Prostředí po přihlášení do systému B.3 Výběr množiny úloh B.4 Výběr úlohy B.5 Kontrola odevzdaných prací B.6 Změna uživatelského nastavení C.1 Formulář pro přihlášení do systému C.2 Nastavení systému C.3 Vytvoření nového předmětu C.4 Vytvoření nové množiny úloh C.5 Vytvoření nové úlohy C.6 Vytvoření nové validační úlohy C.7 Import uživatelů C.8 Vytvoření nového uživatele C.9 Editace záznamů vytvořeného předmětu C.10 Kontrola odevzdaných prací C.11 Vyhledávání duplicitních prací viii

9 Seznam tabulek 5.1 Rozdělení uživatelů do skupin podle počtu bodů z dotazníku Bodové ohodnocení otázek ze závěrečného dotazníku Úspěšnost odevzdání první úlohy Rozdělení uživatelů do skupin v závislosti na vyplněném dotazníku Odpovědi na otázky týkající se vylepšení funkčnosti a vzhledu Procentuální rozdělení uživatelů do skupin podle zkušeností ix

10 KAPITOLA 1. ÚVOD 1 1 Úvod Při stoupajících požadavcích na praktické znalosti studentů z programování je výhodné jejich znalosti ověřit, a to i bez přítomnosti dalších osob. Na Západočeské univerzitě v Plzni (ZČU) je již několik let úspěšně využíván systém, který umožňuje testování a hodnocení studentských prací. Tento systém se v praxi velice osvědčil a nyní jej zavádí i Fakulta elektrotechnická Českého vysokého učení technického v Praze (FEL ČVUT). Tato diplomová práce se zabývá tvorbou webové aplikace pro odevzdávání studentských prací. Součástí je validátor dodaný ZČU, který mimo syntaktických a sémantických pravidel kontroluje také funkční správnost kódu. Práce se dále zabývá tvorbou modulu pro vyhledávání duplicitních prací. Nemalá část je věnována transformaci objektového modelu do relačního databázového schématu. Práce je rozdělena do šesti kapitol. První kapitolou je tento úvod zabývající se důvody vzniku systému, ve druhé kapitole je stručný přehled problémů týkajících se tvorby práce, třetí kapitola je zaměřena na analýzu implementace a návrh řešení, čtvrtá kapitola obsahuje podrobný popis metod a funkcí použitých během realizace, pátá kapitola je věnována testování aplikace a šestá kapitola je shrnutím výsledků diplomové práce. 1.1 Důvody vzniku systému Systém je navržen především pro školy a vzdělávací instituce, kde je nutné odevzdávat úlohy elektronickou cestou. Příkladem může být předmět Algoritmizace vyučovaný Katedrou počítačů FEL ČVUT. Studenti jsou seznamováni se základy programování a během semestru odevzdávají domácí úlohy (zdrojové kódy). V současné době je každý student nucen odevzdat domácí úlohu em. Nemá tak žádnou jistotu, že úloha úspěšně dorazila. Ale především bude o výsledku své práce informován po nějakém čase, až vyučující úlohu přijme a překontroluje. Každý vyučující může vést více než jedno cvičení a na každém může být až 20 studentů. Toto pro něj představuje velké časové vytížení při zpracování zaslaných prací, při jejich opravování, hodnocení a při zapisování výsledků. Systém, který by umožňoval přijmout soubory od více uživatelů a v případě zdrojového kódu soubor automaticky překontroloval, ohodnotil a bez prodlení zaslal výsledky uživateli by celou proceduru odevzdání výrazně zjednodušil.

11 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 2 2 Popis problému, specifikace cíle Hlavním cílem práce je vytvořit webový systém pro odevzdávání studentských prací. Systém automaticky pozná, je-li odevzdaná práce zdrojový kód vytvořený v programovacím jazyce Java a umožní jeho kontrolu funkční správnosti pomocí externího validátoru. 2.1 Popis řešeného problému Zcela obecně představuje odevzdávací systém webovou prezentaci, která umožňuje odevzdání prací a jejich automatickou kontrolu. V detailním pohledu je to systém, který v sobě sdružuje webový, databázový a aplikační server. Na aplikačním serveru může běžet několik podpůrných aplikací, z nichž nejvýznamnější je validační. Proto je dále v textu aplikační server označován jako validační. Registrovaný uživatel se do systému přihlašuje přes webové rozhraní, kde má možnost odevzdat vypracovanou úlohu. Pokud je úloha programovacího charakteru (zdrojový kód), je automaticky přeposlána validačnímu serveru. Ten ji překontroluje a podle předepsaných kritérií automaticky oboduje. Po uplynutí určitého časového intervalu (např. semestr) systém sečte všechny body a uživatele ohodnotí (např. známkou). Kdykoli musí nějaká práce splňovat určité formální požadavky, je možné na její kontrolu použít validační systém. Pokud je například nutné přijímat jen určité typy souborů se specifickým obsahem nebo třeba odevzdané XHTML 1 stránky validovat W3C 2 validátorem nebo vykonávat plno jiných kontrol, je možné využít validačního serveru. Obecně je jakákoli kontrola, u které si odborník dokáže představit, že by ji naprogramoval, proveditelná validačním serverem. 2.2 Vymezení cílů 1. Navrhnout a realizovat webový systém pro odevzdávání souborů. Bude-li se jednat o zdrojový kód, tento systém soubor překontroluje pomocí externího validátoru dodaného Západočeskou univerzitou v Plzni. 2. Navrhnout a realizovat modul pro vyhledávání duplicitních zdrojových kódů. 3. Umožnit hromadný import uživatelů podle předem definovaného XML 3 formátu. 4. Umožnit zobrazení studentů registrovaných do systému podle jejich výsledků, studijních skupin a paralelky tak, aby nebyla porušena ochrana osobních údajů. 5. Umožnit odevzdání prací z více předmětů a tomu podřídit definici rolí jednotlivých uživatelů. 1 XHTML (extensible HyperText Markup Language) - značkovací jazyk určený pro tvorbu hypertextových dokumentů. 2 W3C (World Wide Web Consortium) - mezinárodní konsorcium dohlížející na vývoj internetových standardů. 3 XML (extensible Markup Language) - jazyk umožňující popsat strukturu dokumentu z hlediska věcného obsahu jednotlivých částí.

12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 3 3 Analýza a návrh řešení Tato kapitola popisuje technologie použité během návrhu a realizace systému. Dále se zabývá analýzou abstraktních problémů a cílů práce a jejich přeformulování na konkrétní návrhy řešení. Další část je zaměřena na popis validátoru zdrojových kódů. 3.1 Výběr implementačního prostředí Hlavním kritériem pro výběr technologií uvedených v této části bylo splnění následujících požadavků: stabilita - stabilita a robustnost, uživatelská přívětivost - snadná orientace v prostředí, přenositelnost - platformní nezávislost a přenositelnost, legálnost - k realizaci a provozu nebude použit žádný nelegální software Java Enterprise Edition Java Enterprise Edition [1] (označováno Java EE, dříve J2EE) je standardizovaná platforma určená pro vývoj a provoz podnikových aplikací a informačních systémů. Serverové aplikace na ní postavené se vyznačují především platformní nezávislostí a přenositelností, robustností, škálovatelností a vysokou bezpečností. V základu se jedná o rozšíření 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áři infrastrukturu, která mu usnadní jejich vývoj. Součá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řístup k legacy systémům - Java Connector Architecture (JCA), Hibernate, - pří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ředevším pro vývoj webových aplikací. Vícevrstvé aplikace v Java EE se obecně skládají z těchto vrstev: - prezentační vrstva, - aplikační vrstva, - vrstva persistence dat.

13 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Prezentační vrstva Prezentační vrstva se stará o transformaci dat směrem k uživateli a o zpřístupnění funkcionality aplikace. Nejčastěji se jedná o webovou aplikaci, o klasickou aplikaci s GUI 1 nebo stále častěji i o mobilní aplikaci pro mobilní telefon nebo pro zařízení PDA 2. Pro realizaci webové prezentační vrstvy slouží technologie JavaServlets [3] a JavaServer Pages[9]. Často se používají také různé webové aplikační rámce, obvykle založené na architektuře MVC 3 [4] Aplikační vrstva Aplikační vrstva zajišt uje vlastní funkcionalitu programu. Může být realizována různým způsobem, v jednoduchých případech stačí obyčejná knihovna tříd. Často je však používán nějaký framework, zajišt ující základní služby (perzistence, řízení transakcí, řízení přístupu, vzdálený přístup, dependency injection, apod.). Většina frameworků nabízí tzv. deklarativní přístup. Příkladem je Spring [5] nebo standard Enterprise JavaBeans [6] Vrstva persistence dat Vrstva persistence dat slouží k ukládání dat do nějakého perzistentního úložiště, nejčastěji do relační databáze. Pro komunikaci se používá obvykle JDBC 4, často ve spojení s nějakým nástrojem typu ORM 5 (Java Persistence API [7], Hibernate [8]) 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říponou.jsp, které jsou při prvním požadavku na zobrazení automaticky převedeny servletovým kontejnerem na servlet (.java) a přeloženy do Java třídy (.class). Servlety jsou speciální třídy napsané v jazyce Java, které komunikují s webovým serverem a mohou jednoduše využívat dalších Java tříd. Po jakékoliv další změně.jsp souboru dojde při následujícím požadavku znovu k převodu na servlet a rekompilaci. Následná vyvolání jsou již jen spuštěním metody service() přelož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říslušnou metodu doget, dopost, doput, atd Skriptovací značky JSP byly při svém vzniku funkčností velmi podobné např. jazykům ASP 6 [10] nebo PHP 7 [11]. Části stránky, které se zobrazovaly beze změny se skládaly ze standardních HTML 8 tagů. 1 GUI (Graphical User Interface) - druh komunikace s počítačem mající podobu interaktivních grafických prvků 2 PDA (Personal Digital Assistant) - malý kapesní počítač, ovládaný obvykle dotykovou obrazovkou a perem 3 MVC (Model View Controller) - softwarová architektura, která rozděluje datový model aplikace, uživatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, že modifikace některé z nich má minimální vliv na ostatní 4 JDBC (Java DataBase Connectivity) - registrovaná ochranná známka společnosti Sun Microsystems, Inc. Původní význam je API pro programovací jazyk Java, které definuje jednotné rozhraní pro přístup k relačním databázím. 5 ORM (Object-Relational Mapping)- programovací technika pro konverzi dat mezi relačními databázemi a objektově orientovanými programovacími jazyky. 6 ASP (Active Server Pages) - skriptovací platforma společnosti Microsoft Corporation, primárně určená pro dynamické zpracování webových stránek na straně serveru. 7 PHP (Hypertext Preprocessor) - multiplatformní skriptovací programovací jazyk, určený pro tvorbu dynamických webových stránek. 8 HTML (HyperText Markup Language) - značkovací jazyk určený pro tvorbu hypertextových dokumentů.

14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 5 A části stránky, které se dynamicky měnily byly označeny speciálními JSP značkami, z nichž většina začínala <% a končila %>. Tyto části programovacího jazyka uvnitř HTML se nazývají skriptlety. Tento přístup je dnes zavržený, protože promíchání HTML kódu se skriptlety bylo velmi nepřehledné a samotné stránky se špatně opravovaly a udržovaly. Nicméně kvůli zpětné kompatibilitě JSP dodnes skriptlety podporují a jejich vložení do stránky je umožněno pomocí tří základních značek: - Výraz ve tvaru <% výraz %>, který vytiskne řetězcový výraz či proměnnou přímo do generované stránky. - Skriptlet ve tvaru <% kód %>, který vloží kód na příslušné místo v metodě service() výsledného servletu. - Deklarace ve tvaru <%! kód %>, která vloží kód na určité místo mimo metodu service() výsledného servletu, což se může hodit například k definici pomocné metody pro často se opakující činnosti. Pro více informací o servletech a JSP stránkách může posloužit např. [12] Knihovny značek V dnešní době se při psaní JSP stránek a generování dynamického obsahu používají speciální značky, které vypadají podobně jako XML značky: <prefix:jméno atribut="hodnota"/>, kde prefix určuje příslušnost k určité rodině značek a jméno specifikuje konkrétní značku. Mimo základních značek, 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ří instanci JavaBeanu v daném rozsahu platnosti, <jsp:getproperty name="bean" property="něco" /> - najde atribut bean a zavolá getněco(), <jsp:setproperty name="bean" property="něco" /> - najde atribut bean a zavolá setněco(), je možné použít značky z jiných rodin značek, jejichž použití je nutné deklarovat na začátku JSP stránky:

15 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 6 <%@page contenttype="text/html" %> <%@ taglib prefix="c" uri=" %> <%@ taglib prefix="f" uri=" %> <%@ taglib prefix="moje" uri=" %> Deklarace sváže zvolený prefix se zadaným URI 9, podle kterého se vyhledá knihovna značek. Implementace knihoven značek se přidávají obvykle jako JAR 10 soubory do projektové složky /WEB-INF/lib/. Každá knihovna obsahuje tzv. Tag Library Descriptor (TLD) soubor popisující jaké značky obsahuje JavaServer Faces JavaServer Faces [13] (JSF) je webový framework postavený na programovacím jazyce Java, určený pro vývoj profesionálních webových aplikací. Důvodem pro vznik JSF bylo především striktní oddělení definice uživatelského rozhraní od programování aplikační logiky. Designéři se tak mohou věnovat své práci a nezatěžovat se spletitostmi programovacího jazyka a stejně tak jsou programátoři zbaveni povinností konzultovat svůj kód s designéry. Uživatelské rozhraní je definováno pomocí speciálních XML značek podobných JSP značkám (viz kap Knihovny značek ), kterým jsou předávána data ze standardních Java beanů. Takto je aplikace rozdělena na uživatelské rozhraní (GUI) a aplikační logiku (business logic). JavaServer Faces zahrnují množinu: - předdefinovaných komponent (výpis textu, vstup textu, combo box, atd.) umožňujících uchování stavů, zachytávání událostí, validaci vstupů, konvertování hodnot, definování navigace stránek a dále přináší podporu pro vícejazyčnost a přístupnost, - standardních komponent, - dvě knihovny JSP značek pro zobrazení JSF rozhraní uvnitř JSP stránek, - model událostí řízený na straně serveru, - automatickou správu stavů jednotlivých komponent, - managed Beans, - sjednocený jazyk pro společné použití JSP 2.0 a JSF 1.2. Uživatelské rozhraní je modelováno pomocí komponent, což přináší objektově orientovaný přístup do webového programování. Samozřejmostí je možnost rozšíření standardní množiny komponent o své vlastní nebo o knihovny komponent třetích stran. Je tak možné do stránky umístit například komponentu kalendář a odpadá nutnost psát celý kód ručně. Další neméně významnou výhodou tohoto modelu je možnost testovat každou komponentu nezávisle, jako samostatný program Životní cyklus JSF Celý proces od odeslání dotazu od uživatele prohlížečem až po přijetí odpovědi od serveru probíhá v několika fázích (obr. 3.1): 9 URI (Uniform Resource Identifier) - řetězec znaků s definovanou strukturou, který slouží k přesné specifikaci zdroje informací, hlavně za účelem jejich použití pomocí počítačové sítě. 10 JAR (Java Archive) - platformě nezávislý formát pro archivaci souborů.

16 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 7 HTTP Request Vyvolání požadavku na klientské straně, např. stisknutí tlačítka. Restore View Obnovení předchozího stavu aplikace pro danou session, tj. vytvoření komponentového stromu, který reprezentuje uživatelské rozhraní na straně klienta. Pokud je session prázdná a není co obnovit (např. při prvním zobrazení stránky), přejde se rovnou na fázi Render Response. Apply Request Values Zaslání stavů komponent (např. vyplněného formuláře) na server a volání action metod navázaných na jednotlivé komponenty. Zároveň je dekódován HTTP Request a z jeho položek nastaveny hodnoty komponent. Process Validations Spuštění registrovaných validátorů na testování vstupních dat pro jednotlivé komponenty. Při selhání validace se zaznamenají chybová hlášení od každé komponenty a prostředí na straně klienta je znovu vykresleno, i s chybovými zprávami. Update Model Values Po úspěšné validaci jsou na straně serveru v Java Beanech pomocí setterů nastaveny hodnoty, které jsou navázány na jednotlivé komponenty. Invoke Application Spuštění action metody, navázané na komponentu, která vyvolala HTTP Request. V metodě může být definován klíč pro přesměrování na další stránku. Render Response Zapsání dat do výstupního proudu HTTP Response, tj. vygenerování serverové odpovědi pro klienta. HTTP Response Zobrazení HTTP Response na straně klienta. Obrázek 3.1: Životní cyklus zpracování událostí v JSF. (zdroj [14]) JSF aplikace tedy běží na straně serveru, kde je zabalena do standardního servletového kontejneru (např. Tomcat) a s klientskou částí komunikuje přes HTTP příkazy. Kontejnerem pro JSF komponenty jsou nejčastěji JSP stránky a každá taková stránka je reprezentována komponentovým stromem Navigace v JSF V kapitole Životní cyklus JSF je ve fázi Invoke Application uvedeno, že pro přesměrování na jinou stránku je nutné mít definovaný klíč. Tento klíč je řetězec typu String a jeho popis se definuje v tzv. navigačním pravidle. Všechna navigační pravidla jsou umístěna v XML souboru faces-config.xml, který je uložen v projektovém adresáři WEB-INF. Definice dvou navigačních pravidel může vypadat např. takto:

17 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 8 1 <faces-config> <navigation-rule> 4 <from-view-id>index.jsp</from-view-id> 5 <navigation-case> 6 <from-outcome>singin</from-outcome> 7 <to-view-id>userhome.jsp</to-view-id> 8 </navigation-case> 9 </navigation-rule> <navigation-case> 12 <from-outcome>settings</from-outcome> 13 <to-view-id>su/settings.jsp</to-view-id> 14 </navigation-case> </faces-config> Každé navigační pravidlo (navigation-rule) určuje, jak se dostat z jedné stránky (from-tree-id) na jiné. Navigation-rule element obsahuje libovolný počet navigation-case elementů, které definují, na kterou stránku má být po zavolání klíče (from-outcome) směrováno (to-tree-id). První pravidlo přesně definuje možnost zavolání klíče singin jen ze stránky index.jsp a přesměrování povede na stránku userhome.jsp. Druhé pravidlo je více benevolentnější a povoluje zavolání klíče settings z jakékoli stránky a vždy povede přesměrování na stránku su/settings.jsp. Tento způsob definice navigačního pravidla se může hodit např. při tvorbě položek v menu aplikace, které bývá umístěno na všech stránkách. Action metoda navázaná na komponentu, ve které může vracet klíč pro přesměrování na jinou stránku je definována v tzv. JavaBeaně Java Beans Java Beans [15] jsou třídy napsané v jazyce Java, které slouží ke konfiguraci aplikační logiky a k uchování hodnot komponent pro webové aplikace. K proměnným instance třídy JavaBeans se přistupuje pouze prostřednictvím tzv. setterů a getterů, které umožňují nastavit a přečíst jednotlivé hodnoty. Níže uvedený příklad beany obsahuje metody setter a getter pro přístup k proměnné hodnota a navíc metodu singinbutton_action, která vrací navigační klíč singin pro přesměrování definované v kapitole 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

18 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 9 13 public String singinbutton_action() { 14 return "singin"; 15 } 16 } Java Beans a JSF Na úrovni JavaBeans není nutné vědět jakým způsobem se daná informace uživateli zobrazí nebo jakým způsobem se od uživatele získá. Důležitá je jen konfigurace mapování beany na danou JSF stránku. Každou vytvořenou beanu je nutné pro aplikaci zaregistrovat. Registrace se provádí v XML souboru faces-config.xml, který je umístěn v projektovém adresáři WEB-INF. Jeho obsah může vypadat např. takto: 1 <faces-config> <managed-bean> 4 <description>popis beany</description> 5 <managed-bean-name>index</managed-bean-name> 6 <managed-bean-class> 7 odevzdavacisystem.indexbean 8 </managed-bean-class> 9 <managed-bean-scope>request</managed-bean-scope> 10 </managed-bean> </faces-config> Uvnitř elementu description je uveden popis beany. Uvnitř managed-bean-class je uveden název, přes který se na beanu odkazuje z JSF souboru. Element managed-bean-class definuje fyzickou cestu k beaně. 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čí do příslušné stránky přidat JSF komponenty a namapovat jejich hodnoty na vytvořenou beanu. Na příkladu níže je hodnota zadaná do vstupního pole (h:inputtext) uložena do beany do proměnné hodnota. Atribut required značí nutnost vyplnit vstupní pole textem. Pokud by pole zůstalo prázdné a uživatel by stiskl tlačítko pro přihlášení (h:commandbutton), zobrazila by se výstupní hláška (h:message) o chybějící hodnotě. V opačném případě, když by vstupní pole uživatel vyplnil, došlo by po stisknutí tlačítka k zavolání metody singinbutton_action, která by podle definice uvedené výše provedla přesměrování na stránku userhome.jsp. 1 <h:form id="form1"> 2 <h:inputtext id="text" binding="#{index.hodnota}" 3 required="true" /> 4 <h:message id="message" for="text" /> 5 <h:commandbutton id="button" value="přihlásit" 6 action="#{index.singinbutton_action}" /> 7 </h:form> V kapitole Životní cyklus JSF je zmíněno, že aplikace komunikuje s klientskou částí jen pomocí HTTP příkazů. Z toho vyplývá, že s JavaBeany se pracuje jen na straně serveru a odpadá nutnost mít na klientské stanici nainstalovaný Java Runtime Environment. Pro více informací o technologii JavaServer Faces může posloužit např. [16].

19 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ ICEfaces ICEfaces [17] je ajaxový framework rozšiřující aplikace postavené na platformě Java EE o Ajax 11 [18] technologii. Umožňuje vytvoření tzv. Rich Internet Application 12 [19] s použitím čistého programovacího jazyka Java, bez JavaScriptu [20]. Prezentační vrstva ICEfaces je postavena především na JavaSever Faces standardech. Stejně jako v JSF je uživatelské rozhraní definováno pomocí speciálních XML značek, které umožňují propojení se standardními Java beanami. V základu ICEfaces obsahuje přes 50 připravených JSF ajaxových komponent (např. kalendář, vstupní pole podobné textovým editorům apod.) a velké množství dodatečných efektů a animací ICEfaces architektura Primárním cílem ICEfaces architektury je striktní oddělení čisté Javy od nízkoúrovňového JavaScriptu. Programátor pracuje jen s programovacím jazykem Java a to i přesto, že veškerá komunikace mezi serverovou a klientskou částí je uskutečňována jen pomocí technologie Ajax. Architektura ICEfaces se skládá ze tří hlavních částí (obr. 3.2): Obrázek 3.2: ICEfaces architektura. (zdroj [17]) ICEfaces Framework ICEfaces framework je rozšíření standardního JSF frameworku o vykreslovací fázi. Standardní JSF aplikace po každém vyvolání požadavku na straně klienta na serveru obnoví stavy všech komponent, zašle je prohlížeči a ten celou stránku aktualizuje (viz kap Ž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ě klienta (DOM). Při vyvolání klientského požadavku a následné změně stromu na straně serveru je provedena aktualizace (Incremental DOM Updates) klientského stromu a to jen těch komponent, které to vyžadují. Komunikace mezi serverem a klientem v této fázi probíhá přes tzv. Ajax Bridge. Ajax Bridge Ajax Bridge je přemostění mezi klientským prohlížečem a serverem a koordinuje komunikaci mezi nimi. Tento most je zodpovědný za doručení aktualizačních požadavků (Incremental 11 AJAX (Asynchronous Javascript And XML) - technologie umožňující interaktivní změnu částí webové stránky bez nutnosti znovunačtení celé stránky. 12 RIA (Rich Internet Application) - směr, který se snaží překlenout rozdíly mezi klasickou webovou a desktopovou aplikací.

20 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 11 DOM Updates) od serveru k prohlížeči a podle nich přestavuje klientský strom komponent. Zároveň detekuje události, které uživatel v prohlížeči uskuteční a zasílá je zpět na server (DOM Partial Submit) na počátek životního cyklu příslušných komponent (viz kap Životní cyklus JSF ). Podle výstupu životního cyklu je upraven JSF komponentový strom aplikace, který je následně 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šíření standardních JSF komponent a přidání množiny nových vyspělejších komponent, které umožňují vytvořit efektivnější webovou aplikaci. Všechny komponenty jsou uzpůsobeny pro ajaxovou komunikaci skrz Ajax Bridge a mohou tak být jednotlivě bez ovlivňování jiných komponent aktualizovány, validovány nebo mohou využít automatického doplňování textu Hibernate Hibernate [8] je komplexní nástroj pro perzistenci dat, tj. mapování tříd jazyka Java na tabulky relační databáze. Objekty které se takto mapují se nazývají Entity a je možné s nimi jakkoli manipulovat, případně se na ně databázově dotazovat pomocí jazyka Hibernate Query Language (HQL). Další mechanismy, které Hibernate poskytuje, umožňují transakční zpracování, polymorfní perzistenci, kešování, vlastní datové typy a mnoho dalších Java Persistence API Java Persistence API [7] (JPA) je specifikace standardizující objektově-relační mapování. Jedním z principů této specifikace je umožnit změnu perzistentního nástroje za jiný, bez jakéhokoli vlivu na funkčnost aplikace. To s sebou přináší mnohé výhody, kdy např. při ukončení vývoje jednoho nástroje je možné jednoduše přejít na jiný. Aby taková změna byla možná, musejí mít všechny perzistentní nástroje přizpůsobenou množinu svých vlastností pro JPA. Větš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řizpůsoben od verze Anotace Vlastní mapování objektů na tabulky se ve standardu JPA zapisuje pomocí tzv. anotací, což jsou meta-informace uvedené přímo v java kódu dané entity. Anotace se zapisují bud před atribut třídy (getter ani setter nemusí být definovány) nebo k getteru entitního atributu. Vždy jde použít bud jeden nebo druhý způsob, ne kombinovaně. Kompletní seznam anotací a všech jejich atributů je uveden v balíčku javax.persistence na [23]. Níže uvedený seznam obsahuje nejpoužívanější - označení třídy, která bude převedena na - označení primárního - definuje detaily - definuje vztah - definuje vztah - definuje vztah - definuje vztah - označuje atribut, který nebude - označuje atribut, který bude použit jako BLOB/CBLOB

21 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 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řekládá volání metod na SQL příkazy, udržuje spojení s databází atd. Před první komunikací s databází je nutné vytvořit tzv. Entity Manager Factory (řádek 3), který spravuje jednotlivé Entity Managery. Z něho se před každou databázovou operací vytvoří Entity Manager (řádek 7), který se po dané operaci zavře (řádek 12). Např. takto: 1 // vytvoření Entity manager factory 2 // (jednou pro celé sezení) 3 EntityManagerFactory entitymanagerfactory 4 = Persistence.createEntityManagerFactory("odevsys"); 5 // vytvoření správce entit 6 EntityManager entitymanager 7 = entitymanagerfactory.createentitymanager(); 8 try { 9 // použití správce entit na objekty 10 } finally { 11 // uzavření správce entit 12 entitymanager.close(); 13 } Pomocí vytvořeného Entity Manageru lze běžně manipulovat s daty databáze, např. takto: - načtení jednoho určitého objektu podle jeho id (viz př. 1), - načtení všech objektů určitého typu (viz př. 2), - načtení jednoho určitého objektu podle jeho atributu (viz př. 3), - uložení objektu do databáze (viz př. 4), - odstranění objektu z databáze (viz př. 5), - použití transakčního zpracování. Vrátí-li některý z příkazů uvnitř transakce chybu, zruší se celá transakce (viz př. 6). 1 // př. 1: načtení jednoho předmětu 2 Subject subject = (Subject) entitymanager.find( 3 Subject.class, 4 subjectid); 5 // př. 2: načtení všech předmětů 6 Query query = entitymanager.createquery("select object(s) " + 7 " from Subject as s"); 8 List<Subject> subjectlist = query.getresultlist(); 9 10 // př. 3: načtení jednoho určitého předmětu 11 Query query 12 = entitymanager.createquery("select object(s) from Subject " + 13 " as s where s.code =?"); 14 query.setparameter(0, "Y36ALG"); 15 Subject subject = (Subject) query.getsingleresult(); 16

22 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ // př. 4: uložení objektu do databáze 18 entitymanager.persist(subject); // př. 5: odstranění objektu z databáze 21 entitymanager.remove(subject); // př. 6: transakční zpracování 24 entitymanager.gettransaction().begin(); 25 // příkazy uvnitř transakce 26 entitymanager.gettransaction().commit(); Životní cyklus entity Každá entita se nachází v jednom ze 4 stavů, který se mění voláním příslušných metod přes Entity Manager 3.3: new/transient (nový nebo uložený) - instance, která je mimo správu JPA. Např. nově vytvoř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ření. removed (odstraněný) - objekt, který ještě existuje v podobě instance, ale z databáze je už odstraněný metodou remove(). Obrázek 3.3: Životní cyklus entity. New/transient - objekt mimo správu JPA, managed - objekt pod správou JPA, detached - uzavření Entity Manageru, removed - objekt odstraněn. (zdroj [21])

23 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Modul vyhledávání duplicitních prací Popis modulu Stále častěji se vyskytují případy, kdy jeden student vypracuje úlohu, ostatní ji od něj zkopírují, případně upraví část kódu a podobné řešení sami odevzdají. Nejen, že se v takovém případě jedná o opisování, ale studenti se zároveň připravují o možnost rozšířit si své znalosti a vědomosti při ř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řadit je podle podobnosti Princip funkce V počátcích vývoje byl systém primárně určen pro podporu výuky předmětů Algoritmizace a Programování v jazyku Java, které jsou vyučovány Katedrou počítačů na Fakultě elektrotechnické Českého vysokého učení technického v Praze. V těchto předmětech studenti odevzdávají většinou jednoduché úlohy, napsané v programovacím jazyku Java. Proto je vyhledávání přizpůsobeno na jednoduché zdrojové kódy a důkladnost rozdělena do třech základních úrovní: 1. úroveň - kontrola znak po znaku 2. úroveň - vymazání všech komentářů, bílých znaků, názvu tříd a metod, package a import a následná kontrola znak po znaku 3. úroveň - 2. úroveň + odstranění názvu identifikátorů a porovnání pořadí klíčových slov První úroveň je určena pro vyhledání prací, které jsou naprosto stejné a podvodníky nijak neupravené. Druhá úroveň se zaměřuje především na práce, ve kterých byly pozměněny komentáře, názvy tříd, metod, název package, případně byly přidány mezery nebo změněno řádkování. Třetí úroveň je identická s druhou úrovní, ale navíc dokáže najít i práce, ve kterých byly pozměněny názvy identifikátorů, případně byly přehozeny některé podobné řádky. Při porovnávání dvou prací na třetí úrovni je možné najít např. takto pozměněnou práci: // původní práce int a = 1; int b = 2; // opsaná práce int b = 2; int a = 1; Za klíčová 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řadí klíčových slov je pro každé z porovnávaných prací zaznamenáno a následně porovnáno. Pokud je pořadí všech klíčových slov stejné, úloha je označena jako opis. Tato pravidla jsou zaměřena především na jednoduché úlohy, ale není žádný problém modul o další důkladnější úrovně vyhledávání rozšířit.

24 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Modul importování uživatelů Popis modulu Jak bylo zmíněno v kapitole 1.1 Důvody vzniku systému, systém je navržen především pro školy a vzdělávací instituce, kde se předpokládá velké množství uživatelů. Systém musí být schopen registrace jednotlivých uživatelů, ale samozřejmostí musí být i registrace třeba stovky uživatelů v jednom kroku Uživatelské role S každou úlohou, která má být v systému zadána, pracuje několik typů uživatelů. Jeden může vytvořit předmět, ve kterém se bude úloha odevzdávat. Jiný úlohu vytvoří 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řesně stanovené oprávnění, co může a co nemůže dělat. Aby systém rozpoznal, který uživatel může například zadávat úlohu a který ji můž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 Role Student Student má možnost přihlásit se do systému pod svým uživatelským jménem, heslem a předmětem, do kterého je zaregistrován. Každý student vidí všechny úlohy, které byly vytvořeny pro jeho předmět, případně pro jeho cvičící skupinu a může je odevzdat. Dále má možnost prohlížet všechny svoje odevzdané úlohy a výsledky jejich validace. Student může měnit své kontaktní údaje Role Učitel Učitel má stejně jako student možnost přihlásit se do systému pod svým uživatelským jménem, heslem a předmětem, do kterého je zaregistrován. Může vytvářet nové množiny úloh pro studenty ze svých cvičících skupin. Úlohy můž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 studentů ze svých cvičících skupin (včetně svých). Učitel může také přidávat nové uživatele s rolí student a měnit osobní údaje všech uživatelů z jeho cvičících skupin. Dále může měnit parametry vytvořených množin úloh Role Administrátor Administrátor se může přihlásit se do systému pod svým uživatelským jménem, heslem a předmětem, do kterého je zaregistrován. Může vytvářet nové množiny úloh pro všechny studenty ve vybraném předmětu. Úlohy můž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 studentů z vybraného předmětu. Administrátor může také přidávat nové uživatele s rolemi student a učitel a měnit osobní údaje všech uživatelů z jeho cvičících skupin (včetně svých). Dále může měnit parametry vytvořených množin úloh Role Super uživatel Super uživatel má stejná oprávnění jako Administrátor, ale nemusí se do systému přihlašovat pod žádným předmětem, respektive se může přihlásit pod jakýmkoli předmětem. Navíc má možnost vytvořit nový předmět a novou cvičící skupinu a zaregistrovat do nich nové

25 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 16 uživatele s rolemi student, učitel, administrátor a super uživatel a měnit osobní údaje všech uživatelů v systému (včetně svých). Dále může měnit parametry všech předmětů, množin úloh a cvičících skupin. Super uživatel může nastavit cestu k externímu validátoru, který se bude používat pro validaci zdrojových kódů XML šablona Uživatelé systému s rolí učitel, administrátor nebo super administrátor mohou do systému přidávat nové uživatele. Aby nemuseli každého uživatele přidávat zvlášt, zahrnuje systém vlastnost pro hromadný import uživatelů z předem definovaného XML souboru. Extensible Markup Language (XML) je obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Umožňuje snadné vytváření konkrétních značkovacích jazyků určených např. pro výměnu dat mezi aplikacemi. Jazyk umožňuje popsat strukturu dokumentu z hlediska věcného obsahu jednotlivých částí. Pro import uživatelů do Odevzdávacího systému byl pomocí XML vytvořen značkovací jazyk s níže uvedenými párovými značkami. Značky, které jsou nezbytné pro správný import jsou označeny slovem povinné. import - uvnitř jsou jednotliví uživatelé, každý označen značkou user (povinné) user - uvnitř jsou atributy jednoho uživatele (povinné) nickname - přihlašovací jméno (povinné) password - přihlašovací heslo right - uživatelská role (user, teacher, admin) (povinné) firstname - jméno (povinné) lastname - příjmení (povinné) - (povinné) locale - preferovaný jazyk systému (cs, en) subjects - uvnitř jsou jednotlivé předměty, každý označen značkou subject subject - kód předmětu (povinné) classes - uvnitř jsou jednotlivé třídy, každá označena značkou class (povinné jen pokud značka right obsahuje atribut user nebo teacher) class - uvnitř jsou atributy jedné třídy (povinné, je-li uvedena značka classes) number - číslo cvičící skupiny (povinné, je-li uvedena značka classes) group - číslo paralelky (povinné, je-li uvedena značka classes) Není-li vyplněna značka password, bude v případě použití systému pro Fakultu elektrotechnickou Českého vysokého učení technického v Praze použit pro autentizaci uživatelů interní ověřovací systém. Pomocí XML souboru nelze z důvodu bezpečnosti importovat uživatele typu Super uživatel. Při nevyplnění značky locale je uživateli nastaven výchozí jazyk čeština. Níže je uveden fragment XML souboru, který po načtení do systému vytvoří nového uživatele Karla Vomáčku.

26 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 17 1 <?xml version="1.0"?> 2 <import> <user> 5 <nickname>vomacka</nickname> 6 <password>heslo</password> 7 <right>teacher</right> 8 <firstname>karel</firstname> 9 <lastname>vomáčka</lastname> 10 < >makacka@fel.cvut.cz</ > 11 <locale>cs</locale> 12 <subjects> 13 <subject>y36pjv</subject> 14 </subjects> 15 <classes> 16 <class> 17 <number>101</number> 18 <group>1</group> 19 </class> 20 <class> 21 <number>102</number> 22 <group>1</group> 23 </class> 24 </classes> 25 </user> </import> 3.4 Validátor zdrojových kódů Validátor zdrojových kódů použitý v Odevzdávacím systému byl dodán Katedrou informatiky a výpočetní techniky Západočeské univerzity v Plzni. Některé části textu v této kapitole se opírají o dokumentaci dodanou společně s validátorem [25] 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ř. zdrojový kód napsaný v programovacímu jazyku Java, musí být práce určitým způsobem překontrolována a uživateli sdělen výsledek kontroly. Kontrola zdrojového kódu probíhá za pomocí tzv. validátoru. Validátor je samostatná aplikace, běžící mimo Odevzdávací systém. Vzdálené spojení je zprostředkováno pomocí RMI 13 a během něho je validátoru zaslán zdrojový kód. Ten je ihned po přijmutí přeložen a pokud je vše korektní, je z kódu nově vzniklá aplikace pomocí validátoru spuštěna. Při každém požadavku o vstupní data, jsou postupně vkládány kontrolní hodnoty, které byly vytvořeny zadavatelem úlohy. Po skončení aplikace jsou přečtena její výstupní data (označena speciálním řetězcem, aby se nemohla splést s jinými daty) a jsou překontrolována s výstupními daty vzorové úlohy. Vzorová úloha je program vytvořený zadavatelem úlohy, který slouží jako etalon během validace. Jsou-li data stejná, úloha je ozna- 13 RMI (Remote Method Invocation) - rozhraní umožňující objektu z jednoho virtuálního stroje (JVM) volat metody jiného objektu z jiného virtuálního stroje