Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT-5214-47956 Michal Behúň Automatizované vyhodnocovanie HDL modelov Bakalárska práca Študijný program: Počítačové systémy a siete Študijný odbor: 9.2.4 Počítačové inžinierstvo Miesto vypracovania: Ústav informatiky a softvérového inžinierstva, FIIT STU Bratislava Vedúci bakalárskej práce: Ing. Katarína Jelemenská, PhD Máj 2010
Ja dole podpísaný Michal Behúň čestne prehlasujem, že túto prácu som vypracoval samostatne, s použitím uvedených informačných zdrojov.... Michal Behúň
Ďakujem svojmu projektovému vedúcemu Ing. Kataríne Jelemenskej, PhD za jej pomoc, cenné rady a vybavenie, ktoré mi poskytla pri realizácii môjho projektu. Ďalej chcem poďakovať celej mojej rodine, kamarátom a mojej skvelej priateľke, ktorí ma podržali pri ťažkých chvíľach počas dlhých bezsenných nocí strávených nad prácou.
ANOTÁCIA Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: POČÍTAČOVÉ SYSTÉMY A SIETE Autor: Michal Behúň Bakalárska práca: Automatizované vyhodnocovanie HDL modelov Vedúci bakalárskej práce: Ing. Katarína Jelemenská, PhD Máj 2010 Táto práca sa zaoberá problematikou automatického hodnotenia. Tieto systémy majú uľahčovať učiteľom prácu pri hodnotení práce študentov. Cieľom práce je vytvoriť automatický systém, ktorý má pomáhať učiteľovi pri hodnotení HDL modelov odovzdaných študentmi. Systém musí byť jednoducho použiteľný, musí byť efektívny pri spracovávaní väčšieho množstva zadaní. Takýto systém veľmi uľahčí proces odovzdávania a hodnotenia zadaní. V časti analýza sú opísané existujúce systémy na automatické hodnotenie. Vybrané systémy sú popísané dôkladnejšie, hlavne z pohľadu algoritmov použitých na spracovanie a ohodnotenie kódu. Jeden z týchto algoritmov je popísaný dôkladne a následne použitý pre naše účely. Ďalej sa tu nachádza popis, história a niektoré základné verzie jazykov HDL. Výsledok analýzy nás viedol k vytvoreniu systému, ktorý používa popísané algoritmy na ohodnotenie zadaní študentov. Systém pozostáva z dvoch modulov, ktoré hodnotia zadania z dvoch systémov používaných na škole. V budúcnosti je možné tento systém rozšíriť o podporu viacerých jazykov ako je SystemC alebo HandelC alebo o spracovanie v paralelnom prostredí.
ANNOTATION Slovak University of Technology Bratislava FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES Degree Course: COMPUTER SYSTEMS AND NETWORKS Author: Michal Behúň Bachelor Theses: Automated assessment of HDL models Supervisor: Ing. Katarína Jelemenská, PhD 2010, May Presented thesis deals with the problem of automated assessment. These systems have facilitated the work of teachers in assessing student work. The aim of this work is to design and to implement automated system to help teacher with grading an assessment of HDL models submited by students. System will have to be very easy to use, it must be efficient in processing large amounts of submisions. This system will facilitate the submiting process and assignments. Existing systems for automated assessment are described in analysis. Some of the systems are described in depth, particularly in terms of algorithms used for code processing and evaluation. One of those algorithms is described in deep and used for our purpose. There is also the description, history and some basic versions of HDL languages. Analysis result led us to the desing of a system which uses the described algorithms for grading student s work. The system has two modules for grading assignments from two systems already used at our faculty. It is possible to enhance designed systems with support for more languages like SystemC or HandelC or support for parallel processing in the future.
Obsah 0 Úvod 1 1 Analýza 2 1.1 Automatizovanie hodnotenia........................ 2 1.1.1 1. generácia - prvé hodnotiace systémy.............. 3 1.1.2 2. generácia - nástrojovo orientované systémy.......... 3 1.1.3 3. generácia - webovo orientované systémy............ 6 1.2 Porovnávanie reťazcov........................... 7 1.2.1 Prvá fáza: normalizácia....................... 8 1.2.2 Druhá fáza: Syntaktické porovnávanie............... 9 1.2.3 Tretia fáza: Sémantická analýza.................. 9 1.2.4 Štvrtá fáza: kombinovaný index podobnosti........... 10 1.2.5 Piata fáza: Finálna analýza.................... 10 1.3 Jazyk HDL................................. 10 1.3.1 Hardware Description Language.................. 10 História HDL............................ 11 Návrh pomocou HDL........................ 11 Simulácia a ladenie kódu HDL................... 12 1.3.2 Typy HDL jazykov......................... 12 VHDL................................ 12 Verilog................................ 13 1.4 Zhrnutie analýzy.............................. 14 2 Návrh 15 2.1 Špecifikácia požiadaviek.......................... 15 2.2 Návrh samotného systému......................... 16 2.2.1 Porovnávací algoritmus....................... 17 2.2.2 Hodnotiaci algoritmus....................... 18 2.2.3 Popis rozhrania........................... 19 2.2.4 Návrh pre paralelné spracovanie.................. 20 i
3 Implementácia 21 3.1 Implementačné prostredie......................... 21 3.2 Popis implementácie............................ 21 4 Zhodnotenie 22 4.1 Možnosti zlepšenia systému........................ 23 Literatúra 24 A Technická dokumentácia 26 A.1 Popis zdrojových súborov......................... 26 A.2 Používateľská príručka........................... 27 B CD-ROM 28 ii
Úvod Vzdelávanie je cieľavedomý proces získavania poznatkov, zručností a vedomostí. Proces vzdelávania sa vyvíja už od čias starovekého Grécka a Rímskej ríše. K procesu vzdelávania neodmysliteľne patrí hodnotenie. Hodnotenie má za úlohu povedať žiakovi, ako úspešne zvládol vzdelávací proces, má motivačný charakter. Časom sa vyvíjali rôzne systémy hodnotenia žiakov. Veľký krok znamenalo začatie používania počítačov vo vzdelávacom procese. Tento krok umožňoval využiť ich výkon aj na hodnotenie žiakov. Vznikli teda rôzne systémy na automatické ohodnotenie práce študentov. Tieto systémy majú na základe vopred daných kritérií otestovať a ohodnotiť prácu študenta tak, ako by ju ohodnotil učiteľ. Od jednoduchých programov, ktoré dokázali len otestovať spustiteľnosť programu, ktorý napísal študent, až po komplexné systémy. Takéto systémy dovoľujú testovať práce študentov podľa rôznych kritérií, dokážu ohodnotiť nielen celok, ale aj časti práce, dokážu odhaliť plagiátorstvo a ponúkajú študentom možnosť prezerať si ich výsledky vzdialene prostredníctvom internetu. Náplňou tejto práce je vytvorenie systému automatického hodnotenia HDL modelov na základe určitých vzoriek. Dôraz je kladený na jednoduché používanie aj pri väčšom množstve spracovávaných prác. Možnosťou je rozšírenie funkcionality o vykonávanie v paralelnom prostredí. Dokument je rozdelený na viacero kapitol. úvodná kapitola obsahuje stručný úvod do problematiky a ciele práce. V prvej kapitole je analýza problému a problémovej oblasti. Obsahuje stručnú históriu vývoja systémov na automatické hodnotenie a popis niekoľkých existujúcich riešení. ďalej obsahuje popis jazyka HDL, na ktorý bude tento systém špecializovaný. V Druhej kapitole je opísaný prvotný návrh riešenia, použité algoritmy a špecifikácia požiadaviek. 1
Analýza 1.1 Automatizovanie hodnotenia Programovacie problémy a úlohy sú považované za podstatné prvky softvérového inžinierstva a informatického vzdelávania. Programovacie úlohy pomôžu študentom oboznámiť sa s modernými programovacími jazykmi, oboznámiť sa so základnými nástrojmi a pochopiť, ako môžu použiť princípy vývoja softvéru a dizajnu. Hodnotenie týchto úloh kladie značné nároky na inštruktorov čas. Inštruktor musí určiť, do akej miery splnil študent požiadavky zadania a overiť originalitu jeho programu. Systémy, ktoré automaticky vyhodnocujú programovacie úlohy študentov sa používajú viac ako štyridsať rokov. Tieto systémy majú niekoľko výhod. Napríklad hodnotenie programovacích úloh je časovo náročný proces a pedagóg môže tento čas využiť efektívnejšie. Je teda jasné, že dobre navrhnutý a dobre používaný systém môže ušetriť učiteľovi veľa času. ďalšou výhodou je, že ľudské hodnotenie je často omylné. Strojové hodnotenie je väčšinou úplne objektívne (za predpokladu, že je dostatočne dobre nastavené). Existujú samozrejme nevýhody. Jedným z hlavných nedostatkov metodiky automatického hodnotenia je jeho nepružnosť, ktorá bráni pri posudzovaní a hodnotení zložitejších otázok. Automatické hodnotenie nie je pružné, pretože vopred určuje rozhranie, cez ktoré sa testuje študentova práca. Problém nastáva aj vtedy, ak sa testuje program po častiach. Jednotlivé základné bloky kódu môžu byť opísané viacerými spôsobmi. Akokoľvek môže byť systém dobre navrhnutý, vždy bude potreba kontroly človekom. Nemalo by byť cieľom nahradiť učiteľa, systém by mal byť akýmsi podporným nástrojom. [1] Generácie systémov na automatické hodnotenie Existujú tri generácie testovacích hodnotiacich systémov. Prvá generácia systémov predstavuje prvé pokusy o automatizáciu testovania a sú považované za skutočnú inováciu vo vzdelávacom procese. Ich použiteľnosť je však obmedzená na konkrétne laboratória. Systémy druhej generácie sú charakteristické použitím nástrojov ovláda- 2
ných príkazovým riadkom, niekedy s použitím grafického rozhrania. Tretia aktuálna generácia systémov využíva moderné webové technológie a niekedy poskytujú dodatočnú podporu pre pedagógov v podobe možnosti nastavenia parametrov hodnotenia. Tretia generácia hodnotiacich systémov začína ponúkať aj služby mimo hraníc laboratória vďaka nástrojom, ktoré umožňujú komunikáciu študenta s hodnotiacim systémom pomocou internetu. [2] [3] 1.1.1 1. generácia - prvé hodnotiace systémy Automatizované hodnotiace systémy vznikajú, od kedy študenti vytvárajú svoj vlastný softvér. Prvý príklad automatizovaného testovania programových úloh možno nájsť v práci J. Hollingswortha [4]. Namiesto použitia prekladačov a textových editorov, študenti odovzdávali programy vytvorené v asembleri na diernych štítkoch. Vzorový program a program napísaný študentom boli spustené a ich výstupy sa porovnali. Mohli byť vrátené dva rôzne výsledky, a to buď zlá odpoveď alebo kompletný program. Výhoda tohto systému nepozostávala iba v dobrom využití času pedagóga, kľúčová výhoda bolo efektívne využitie výpočtových zdrojov, čo umožnilo väčšiemu počtu študentov učiť sa programovanie. Ako sa programovacie systémy vyvíjali, zároveň s nimi sa vyvíjali hodnotiace systémy. G. E. Forsythe a N. Wirth spolu s P. Naurom, predstavili hodnotiaci systém, ktorý hodnotil programy napísané v jazyku Algol. Systém funguje pomocou hodnotiaceho programu na testovanie odovzdaných programov. Tento systém obsahoval tri základné funkcie: vykonávať testovanie dát, merať dobu behu programu a spravovať tzv. žiacku knižku. Niekoľko nových myšlienok zaviedli J. B. Hext a J. W. Winnings. Testovanie programov bolo vykonané na základe porovnania vzorových údajov a dát získaných spustením programov odovzdaných študentami. Po vykonaní testov bola vygenerovaná správa, vrátane podrobných výsledkov testov. Zaujímavé je, že autori tvrdili, že je možné použiť výsledky na kontrolu plagiátorstva (na základe veľkosti a doby behu odovzdaného programu). Systémový návrhári potom často riešili problém plagiátorstva. Hollingsworth veril, že je možné, aby študent odovzdal program, ktorý by spôsobil úmyselne škodu hodnotiacemu softvéru. Tento problém pretrváva dodnes, a z toho vyplýva otázka bezpečnosti. 1.1.2 2. generácia - nástrojovo orientované systémy Vývojom a používaním prvej generácie testovacích systémov sa získali veľké skúseností. Druhá generácia systémov sa voľne označuje ako nástrojovo orientovaná. Táto generácia systémov bola často implementovaná v podobe aplikácie príkazového riadku 3
alebo programov s grafickým rozhraním. Príkladom druhej generácie hodnotiacich nástrojov je práca T. A. Scotta a P. C. Isaacsona. Autori uvádzajú, že hodnotenie programovacích úloh zahŕňa dve činnosti: kontrola správnej funkcie programu a kontrola, či bol rozumne použitý programovací štýl. Rovnako ako predchádzajúce hodnotiace systémy (a všetky systémy od vtedy), hlavný dôraz sa kladie na správnu funkčnosť odovzdaného programu. Scott a Isaacson opísali skriptový prístup k testovaniu. Skript zoberie sadu súborov v kolekcii adresárov a snaží sa o preklad každého súboru a otestovať každý program pomocou preddefinovaných testovacích dát. Výsledky kompilácie sa zapisujú do súboru, ktorý môže učiteľ prezerať. V tom istom roku bol predstavený systém TRY K. A. Reekom [6]. Tento systém hlavne orientovaný na študenta. TRY umožňuje študentom otestovať svoje programy a následne si prezrieť výsledky testovania. Každý skúšobný pokus je zaznamenaný. Rovnako ako iné systémy tejto generácie, testy sa vykonávajú jednoduchým porovnávaním znak po znaku podľa predpokladaného výstupu. Reek uviedol dva zaujímavé poznatky. Po prvé, vykonanie cudzieho kódu v produkčnom prostredí môže viesť k nežiaducim výsledkom, ako napríklad k zastaveniu alebo poškodeniu systému alebo údajov v ňom obsiahnutých. Reek tiež uviedol vlastný odlišný pohľad na didaktické dôsledky použitia automatizovaného testovacieho systému. Namiesto toho, aby študenti mali neobmedzený počet pokusov, jeho systém obmedzuje študentov stanoveným počtom, koľko krát môžu odovzdať program. Študenti sú preto nútení premýšľať o činnosti svojho programu dôkladnejšie pred tým, ako ho odovzdajú na posúdenie a testovanie. Projekt Kassandra [7] predstavuje zaujímavý vývoj, pretože umožňuje testovanie programov napísaných v prostredí Matlab a Maple (matematické jazyky), rovnako ako v tradičnom prostredí Oberon. Správnosť odovzdaného programu je opäť testovaná porovnaním výstupných dát a referenčných testovacích dát, ktorý sú vytvorené učiteľom. Inovácia spočíva v odlišnom spôsobe odovzdania pomocou internetových soketov, ktorá umožňuje stupeň izolácie testovacieho a vývojového prostredia. Systém ASSYST bol vyvinutý D. Jacksonon a M. Usherom [6]. Autori zavádzajú systém, ktorý analyzuje zadanie podľa celej rady kritérií. ASSYST analyzuje, či výstup odovzdaného programu je správny (opäť podľa porovnania výstupu s niekoľkými preddefinovanými testovacími dátami), či je program efektívny pri využívaní CPU a aké majú hodnotenie na základe zložitosti a štýlu programovania. Jeden z najväčších prínosov tohto projektu je pochopenie, že automatizovaný systém hodnotenia tiež môže 4
byť nápomocný pri celkovom hodnotení. Tento systém poskytuje mechanizmy pre spracovanie zadania, vytváranie a generovanie správ a umožňuje použiť váhy, ktoré sú používané pre rozličné časti hodnotenia. Systém BOSS vznikol na Univerzite vo Warwicku vo Veľkej Británii. Jeho pôvodná špecifikácia bola podobná systému ASSYST. Oba bežali na operačnom systéme Unix a hodnotiace programy boli napísané v jazyku C. Prvú verziu systému BOSS tvorila sada jednoducho použiteľných programov v príkazovom riadku. Študent mohol použiť jeden program na vykonanie testu a zistenie, či je jeho zadanie správne, alebo použiť program na odovzdanie zadania do bezpečného miesta, kde je hodnotené učiteľom. Rovnako ako mnoho iných inštitúcií počítačovej vedy v tom čase, Univerzita vo Warwicku začala používať jazyk Java vo výučbovom procese. To si vyžadovalo transformáciu systému. Výsledný systém sa skladal z dvoch hlavných prvkov. Testovací program, ktorý je Java GUI aplikáciu a programom na hodnotenie a správu aplikácie pre učiteľa. Jeden z najpozoruhodnejších systémov vyvinutých v polovici osemdesiatych rokov bol systém Ceilidh vyvíjaný na Nottinghamskej Univerzite [9], kde bol používaný trinásť rokov, než bol nahradený systémom CourseMarker. Ceilidh bol založený na automatickom hodnotiacom mechanizme, ktorý testoval a hodnotil programy z niekoľkých hľadísk: kontrola správnosti funkcie programu a programovací štýl (tj. elegancie riešenia). Prvá verzia systému Ceilidh bola vytvorená na podporu kurzov programovania v C, ale jeho rozšíriteľná povaha znamenala, že ostatné testovacie nástroje boli vytvorené veľmi rýchlo. Ceilidh bol inštalovaný vo viac ako 300 prevádzkach po celom svete. Ceilidh však mal niekoľko obmedzení. Nemal žiadnu podporu sietí, študenti sa museli prihlásiť na klienta na rovnakom stroji ako server a nemal plné X-Windows a PC-Windows grafické rozhranie. Okrem toho, vylepšenia v priebehu rokov nekontrolovateľne rástli a bolo ťažké tento systém udržiavať. Koniec koncov fungoval na platformách Unix. Zatiaľ čo väčšina systémov vyhodnocuje softvér napísaný v jazyku C alebo Java, existujú niektoré, ktoré hodnotia kód napísaný vo viacerých exotických jazykoch. Systém Scheme-Robo, opísaný R. Saikkonenon, automaticky vyhodnocuje programy napísané v jazyku Scheme. Jeden z rozdielov medzi týmto projektom a ostatnými je, že testovanie prebieha prostredníctvom e-mailového rozhrania, pôvodne vyvinutého pre systém TRAKL. Druhá generácia systémov naďalej pokračovala vo vývoji. Projekt Scheme- Robo bol doplnený o grafické užívateľské rozhranie a algoritmus na animovanie súčasti. Niektoré systémy druhej generácie sa vyvinuli do systémov tretej generácie tzv. we- 5
bovo orientovaných systémov. 1.1.3 3. generácia - webovo orientované systémy Zatiaľ čo druhá generácia nástrojov bola často charakterizovaná rozhraním príkazového riadku a manuálnou údržbou skriptov, systémy hodnotenia tretej generácie využívajú internetové technológie a čoraz sofistikovanejšie testovacie postupy. CourseMarker [3] vyvinutý na Nottinghamskej Univerzite nadväzuje na systém Ceilidh. Zlepšuje ho však v mnohých ohľadoch: po prvé, plne podporuje prácu so sieťou, čo umožňuje klientom byť inštalovaným oddelene od serverov, má grafické rozhranie, ktoré značne zjednodušuje študentov pohľad na systém a bol vyvinutý v jazyku Java, čo znamená, že je prenosný a beží na rôznych platformách. Prvýkrát bol použitý v septembri roku 1998. CourseMarker definuje štyri typy užívateľov: študenti, lektori, učitelia a správcovia. Jedným z najzaujímavejších prínosov je zavedenie tzv. diagramového systému hodnotenie a jeho podpora pre rôzne jazyky vrátane Prolog, SQL, a FORTRAN. Ohodnotenie sa vykonáva automatizovaným mechanizmom, ktorý analyzuje program pomocou celej rady kritérií, s dôrazom na návrh programu. Hodnotiace kritériá sú formát programu (typografické, lexikálne štruktúry a prítomnosť špecifických vlastností), fungovanie programu s testovacími dátami (dynamické testovanie), zložitosť programu a účinnosť (časová náročnosť). Hodnotiace kritériá sú definované v konfiguračnom súbore, ktorý vytvára inštruktor. Zatiaľ čo pôvodný systém Ceilidh ponúkal jednoduchý údaj o počte bodov za zadanie, CourseMarker poskytuje študentom oveľa bohatšiu spätnú väzbu. Rovnako, ako je poskytnuté percentuálne hodnotenie, alebo hodnotenie známkou, je možnosť zobraziť tzv. spätno-väzbový strom umožňujúci študentom interaktívne zistiť, kde stratili body. Použitím nástrojov pre správu mohol učiteľ pridávať a odoberať používateľov, upravovať dokumenty, vytvárať a inštalovať nové kurzy, a priradiť oprávnenia používateľom. ďalší vývoj zahŕňa realizáciu otázok s viacerými odpoveďami a prevod všetkých existujúcich projektov systému Ceilidh do formy CourseMarkera. Systém je stále vo vývoji, no len niekoľko drobných opráv bolo doteraz potrebných. Systém BOSS sa tiež naďalej rozvíja. Poskytuje súbor grafických užívateľských rozhraní pre študentov a lektorov a najnovší vývoj zahŕňa aj webový server. To umožňuje učiteľovi prehliadať zadania pomocou tradičného webového prehliadača cez internet. Systém BOSS tiež zavádza modul na odhaľovanie plagiátorstva. 6
C. Daly a jeho kolegovia vyvinuli systém hodnotenia na platforme Java, tzv. RoboProf. Systém používa webový prehliadač a študent píše zadanie programu do textového poľa. Po dokončení sú úlohy preložené a spustené. Nakoniec sa zobrazia výsledky testovania a hodnotenie. Ak je úloha splnená, študent je vyzvaný, aby pokračoval na ďalšej úlohe. Systém sa skladá z 39 problémov delených do rôznych kategórií, napríklad oblasti premenných, kontroly toku, polia a reťazce. RoboProf má zopár obzvlášť zaujímavých čŕt: pojem úrovní, alebo rozdelenie problému na viaceré časti dáva študentovi možnosť vidieť svoj pokrok, automatické hodnotenie je integrované s možnosťou otázok s viacerými možnosťami, ktorá dopĺňa individuálne programovacie úlohy. Otázky s viacerými možnosťami sú generované náhodne, čím sa zníži možnosť študenta opisovať od ostatných študentov. Je tiež zaujímavé, že Daly taktiež prispel k vývoju v odhaľovaní plagiátorstva. Jackson tvrdil, že hodnotenie programovacích úloh by malo zahŕňať aj kontrolu človekom tak isto ako automatickú časť. V tejto práci Jackson predstavuje sériu testov pomocou preddefinovaných testovacích dát, ktorých výsledky sú poskytnuté učiteľovi, ktorý skúma daný program z hľadiska príslušnej dokumentácie a kladie dôkaz na dobrý dizajn v štruktúre programu. Automatizovaný systém pre posudzovanie programovania (ASAP) z Kingstonskej Univerzity je ďalší systém, ktorý má veľa spoločného so staršími typmi systémov. ASAP sa zameriava predovšetkým na výučbu jazyka Java, ktorý sa používa na Kingstonkej Univerzite. Testovanie sa vykonáva pomocou kombinácie analýzy IO tokov a testovanie jednotlivých členských funkcií. ASAP implementoval stratégiu, ktorá je trochu odlišná od ostatných. Prvotný cieľ projektu bolo vytvorenie systému odovzdávania cez virtuálne univerzitné výučbové prostredie. Odovzdávací systém by sa potom naviazal na žiacku knižku, ktorá umožňuje učiteľom zobrazenie zadaní študentov. Hodnotiaci systém bol navrhnutý tak, aby aj ostatné softvérové komponenty mali prístup prostredníctvom webových služieb. Rovnako ako v iných projektoch bol riešený aj problém plagiátorstva. Projekt ASAP spolupracoval s partnerom na inej univerzite na realizácii medzinárodného systému na odhaľovanie plagiátorstva na platforme Java nazvaný JPLAG. 1.2 Porovnávanie reťazcov Systémy spomenuté v kapitole 1.1 používajú rôzne algoritmy počas celého procesu hodnotenia. Najzákladnejšími sú porovnávací algoritmus, refaktorovací algoritmus a hodnotiaci algoritmus. Keďže porovnávanie bude najzákladnejšia časť navrhovaného systému, rozhodol som sa pre podrobnejší popis algoritmu. Problematiku porovnávania reťazcov možno rozdeliť na viacero fáz. V prvej fáze pro- 7
cesu porovnania reťazcov sa porovnajú všetky jednotlivé reťazce a vyhodnotí sa každá explicitná alebo implicitná nepresnosť a vytvorí sa sada dát, ktoré sa použijú pre ďalšie fázy. V druhej fáze prebieha syntaktická analýza reťazcov z odpovede študenta so vzorovými riešeniami a vytvorí sa súbor indexov syntaktickej podobnosti. Tretia fáza analyzuje reťazce zo sémantického hľadiska a vytvára indexy sémantickej podobnosti. Štvrtá fáza kombinuje výsledky zo syntaktickej a sémantickej analýzy. V piatej fáze sa určí, či je daný reťazec správny alebo nie.[5] 1.2.1 Prvá fáza: normalizácia Normalizácia sa vykoná pred samotným porovnávaním. Výhodou použitia tejto fázy je to, že uľahčuje samotný proces porovnávania a znižuje počet reťazcov, ktoré majú byť porovnávané. Prvotná úprava zahŕňa nasledujúce metódy. zmena veľkosti písma na malé: pomerne jednoduchá metóda, ktorá zmení všetky znaky na malé, tým pádom sa nemusí brať ohľad na rozlišovanie veľkosti písmen a rôzne reťazce s rovnakým významom, ktoré boli odlíšené len veľkosťou písma sa stanú rovnocennými. odstránenie bielych znakov pred a za reťazcom: všetky nadbytočné medzery, tabulátory ako aj zlomy riadkov sú odstránené. nahradzovanie špeciálnych znakov: Jedná sa o odstránenie špeciálnych znakov ako podtržník alebo ampersand. Niektoré špeciálne znaky ako apostrof sú odstránené, zatiaľ čo iné špeciálne znaky sa nahrádzajú medzerami. rozšírenie skratiek: Jedná sa o rozšírenie skratiek ako napríklad anglické msg na message. automatická oprava pravopisu: Táto metóda zahŕňa kontrolu pravopisu, identifikuje nesprávne slová a výrazy a automaticky ich opraví nahradením za prvé slovo, ktoré navrhuje slovník. odstránenie predložiek, spojek, častíc: Jedná sa o odstránenie slov, ktoré sú veľmi časté, ale nie sú relevantné pre porovnávanie. zmena slova na jeho koreň: Táto metóda zahŕňa zmenu všetkých slov čo znamená, že zmení každé na ich koreň. 8
1.2.2 Druhá fáza: Syntaktické porovnávanie Druhá etapa zahŕňa výpočet syntaktickej podobnosti medzi reťazcami pomocou rôznych algoritmov a produkuje ako výstup súbor matríc pre index syntaktickej podobnosti. Táto fáza je flexibilná a možno použiť aj iné algoritmy. Základné algoritmy sú popísané nižšie. Hľadanie zhodnosti: Algoritmus jednoducho porovnáva dva reťazce. Ako výsledok porovnania môže byť hodnota 1, čo znamená presná zhoda, alebo 0, ak sa presná zhoda nenašla. Algoritmus Levenshteinovej vzdialenosti: Levensthteinova vzdialenosť medzi dvoma reťazcami je daná minimálnym počtom operácií potrebných na transformáciu jedného reťazca na druhý, kde možné operácie nad reťazcami sú vloženie, zmazanie, alebo nahradenie jedného znaku. Q-gram algoritmus: Q-gramy sa zvyčajne používajú pri približnom porovnávaní reťazcov pomocou posúvania okna dĺžky q cez znaky reťazca a tým vytvorí rad gramov dĺžky q pre porovnávanie. Zhodnosť je potom hodnotená ako počet rovnakých q-gramov v rámci oboch reťazcov. Simon algoritmus: Tento algoritmus používa počet lexikálne podobných susedných znakov obsiahnutých v oboch reťazcoch. Soundex algoritmus: Tento algoritmus využíva zvukovú podobnosť dvoch slov. Zisťovanie miery podobnosti medzi nimi je založený na Soundex algoritme. Ak majú dve slová rovnakú výslovnosť, Soundex skóre bude 1, inak bude skóre 0. Tento algoritmus má niektoré varianty, ako je RefinedSoundex, metaphone a DoubleMetaphone. AlgoMax: Tento algoritmus berie ako vstup dva reťazce a vracia index syntaktickej podobnosti medzi hodnotami 0 a 1, kde 1 znamená dokonalú zhodu. Algoritmus používa kombináciu vyššie spomenutých algoritmov a tým získa päť rôznych skóre. Nakoniec sa jednoducho vráti maximálna hodnotu. 1.2.3 Tretia fáza: Sémantická analýza Tretia fáza zahŕňa výpočet sémantickej podobnosti medzi reťazcami pomocou rôznych sémantických algoritmov a ako výstup vytvorí súbor matíc sémantickej podobnosti. 9
Táto fáza rámca je flexibilná a možno ju prispôsobiť pre použitie rôznych sémantických algoritmov. Každé slovo môže mať mnoho synoným alebo podobných slovných spojení, ktoré majú rôzny význam. Existuje mnoho algoritmov pre výpočet indexu podobnosti medzi dvoma slovami. Väčšina z nich používa algoritmus na určenie najkratšej cesty a ich informačného obsahu pre výpočet indexu podobnosti. Jedným z ďalších algoritmov pre výpočet sémantickej podobnosti je kombinovaný algoritmus text-to-text. Je to jediný sémantický algoritmus, ktorý nie je zameraný jednotlivé slová, ale na skupinu slov. 1.2.4 Štvrtá fáza: kombinovaný index podobnosti Vo štvrtej fáze sa vytvorí tzv. kombinovaný index podobnosti, ktorý sa vyberie z maxima výsledku syntaktickej a sémantickej analýzy pre každý reťazec. 1.2.5 Piata fáza: Finálna analýza Posledná fáza spočíva v tom, že sa nastaví minimálna hodnota indexu podobnosti. Následne sa vypočíta index podobnosti pre všetky páry reťazcov a výsledok sa porovná s nastavenou minimálnou hodnotou. Ak je index podobnosti väčší ako nastavené minimum, je daný reťazec označený ako správny, ak je menší, je označený ako nesprávny. 1.3 Jazyk HDL Keďže navrhovaný systém bude spracovávať len modely opísané v jazyku HDL, uvediem aj kapitolu, ktorá sa venuje opisu HDL jazykov, stručnú históriu tohto jazyka a niektoré verzie HDL jazykov používaných v súčasnosti. 1.3.1 Hardware Description Language Hardware description language, alebo HDL je jazyk z triedy počítačových jazykov alebo programovacích jazykov pre formálny opis elektronických obvodov. Môžeme ním popísať funkciu, ktorú obvod vykonáva, jeho dizajn a organizáciu a testy na overenie jeho fungovania pomocou simulácie [10]. Modely HDL textovo vyjadrujú priestorovú a časovú štruktúru a správanie sa elektronických systémov. HDL syntax a sémantika zahŕňa jednoznačnú notáciu pre vyjadrenie súbežnosti a paralelizmu. Avšak, na rozdiel od väčšiny programovacích jazykov, HDL aj explicitne vyjadruje čas, ktorý je hlavným atribútom hardvéru. HDL modely sú používané na opísanie spustiteľnej špecifikácie hardvéru. Simulačný 10
program, ktorého cieľom je vykonávať základnú sémantiku jazyka spolu so simuláciou priebehu času, ponúka dizajnérovi možnosť otestovať model hardvéru skôr, ako je fyzicky vytvorený. História HDL Prvé jazyky opisujúce hardvér boli ISP (Instruction Set Processor) vyvinutý na Carnegie Mellonskej univerzite, a KARL vyvinutý na Univerzite v Kaiserslautern, oba okolo roku 1977. ISP bol však skôr viac programovací jazyk používaný na opis vzťahov medzi vstupmi a výstupmi obvodu. Preto ho bolo možné použiť na simuláciu návrhu, nie však k syntéze obvodu. Súčasťou jazyku KARL bola podpora štruktúrovaného hardvérového dizajnu, ktorý bol základom interaktívneho grafického jazyka ABL. Bol implementovaný začiatkom 80. rokov ako grafický VLSI dizajn editor AB- LED centrom výskumu telekomunikácií CSELT v Talianskom Turíne. V polovici 80. rokov, bol VLSI dizajn implementovaný do KARL a ABL jazykov medzinárodným konzorciom financovaným Komisiou Európskej únie. V roku 1983 Data-I/O predstavil jazyk ABEL. Bol určený pre opis programovateľných logických zariadení a v podstate slúžil pre návrh konečných automatov. Prvý moderný HDL jazyk, Verilog [12], bol predstavený Gateway Design Automation v roku 1985. Cadence Design Systems neskôr získala práva na Verilog-XL, HDL simulátor, ktorý by sa stal štandardom pre ďalšie desaťročie. V roku 1987 na žiadosť amerického ministerstva obrany začal vývoj VHDL (Very High Speed Integrated Circuit Hardware Description Language) [11]. Počas niekoľkých rokov sa VHDL a Verilog stali dominantnými HDL modelmi v elektronickom priemysle, zatiaľ čo staršie a menej schopné HDL modely postupne vymreli. VHDL a Verilog však majú mnoho rovnakých obmedzení: žiadny HDL model nie je vhodný pre simuláciu zmiešaných analógových obvodov. Špecializované HDL modely (ako boli Conuence) prišli s jednoznačným cieľom, ktorým riešia špecifické obmedzenia Verilogu a VHDL. Napriek tomu sa žiadnemu z nich nikdy nepodarilo nahradiť VHDL alebo Verilog. Návrh pomocou HDL Väčšina návrhov začína spísaním súboru požiadaviek, alebo diagramom na vysokej architektonickej úrovni. Proces písania popisu HDL je veľmi závislý od projektanta a charakteru obvodu. HDL popis často začína na vysokej úrovni algoritmickým opisom, napríklad pomocou Matlabu alebo C++ matematického modelu. V rámci prípravy na syntézu je HDL opis spracovaný rôznymi systémami. Tieto systémy štandardizujú kód, zisťujú nejasné konštrukcie v kóde pred tým, ako môžu spô- 11
sobiť nesprávne vykonanie syntézy, či detekciu bežných chýb v kóde. HDL dizajn spravidla končí vo fáze syntézy. V závislosti na fyzikálnych technológiách (FPGA, ASIC pole hradiel, ASIC pole buniek) nemusí HDL opis hrať významnú úlohu v konečnej fáze tvorby obvodu. Všeobecne možno povedať, čím viac dizajn smeruje k fyzickej realizácii, tým je návrhová databáza čoraz viac spätá so špecifikáciou, ktorá nemôže byť obsiahnutá vo všeobecných HDL opisoch. Napokon je kremíkový čip vyrobený. Simulácia a ladenie kódu HDL Simulácia umožňuje HDL opisu overiť správnosť návrhu, overuje sa, či je špecifikácia dizajnu rovnaká ako implementácia v popise HDL. Umožňuje tiež experimentovať s rôznymi variantami návrhu. Takéto testovanie je rozhodujúce pre úspešný návrh HDL modelu. Overovanie návrhu je často časovo najnáročnejšia časť procesu návrhu. Väčšina počiatočných testov prebieha v prostredí simulátora HDL. Už v počiatočnej fáze návrhu sú tieto testy predmetom častých a významných zmien v obvode. Popis HDL môže byť aj prototypovaný a testovaný v programovateľných logických obvodoch. Hardvérové prototypovanie je pomerne drahšie ako simulácia HDL, ale ponúka reálny pohľad na výsledok návrhu. Prototypovanie je najlepší spôsob, ako zistiť interakciu s inými hardvérovými zariadeniami a hardvérovými prototypmi. 1.3.2 Typy HDL jazykov VHDL VHDL [11] znamená VHSIC hardware description language (VHSIC: very-high-speed integrated circuit). VHDL je jazyk pre popis hardvéru používa v automatizácii návrhu elektronických obvodov a k opisu digitálnych systémov a systémov so zmiešanými signálmi, ako sú programovateľné polia a integrované obvody. Vývoj VHDL bol zahájený v roku 1981 ministerstvom obrany Spojených štátov k riešeniu krízy životného cyklu hardvéru. Náklady na údržbu elektronických zariadení začala byť veľmi vysoká, z dôvodu zastarania technológie. Dôvodom bolo nedostatočné zdokumentovanie častí systémov a používanie širokej škály rôznych nezlučiteľných simulačných jazykov a nástrojov. Požiadavka bola vytvoriť jazyk s veľkými opisnými schopnosťami a ktorý bude pracovať rovnako na akomkoľvek simulátore a bude nezávislý od návrhu alebo použitej technológie. Proces štandardizácie VHDL bol celkom výnimočný. Záujem zo strany priemyslu bol veľmi veľký už v rannom štádiu používania jazyka. Základná verzia jazyka bola predstavené 2 roky pred štandardizáciou. Vďaka tomu začal veľmi skoro vývoj nástrojov pre VHDL jazyk. Všetky práva k jazyku boli presunuté na IEEE s cieľom podporiť 12
prijatie jazyka priemyslom. Prehľad histórie VHDL 1981 Začatie riešenia hardvérovej krízy 1983-85 Vývoj prvej verzie jazyka firmami Intermetrics, IBM a TI 1986 Všetky práva presunuté na IEEE 1987 Publikácia IEEE štandardu 1987 Vojenský štandard 454, požiadavka komplexného VHDL popisu s každým novým ASIC obvodom 1994 Revízia štandardu (pomenovaný VHDL 1076-1993) 2000 Revízia štandardu (pomenovaný VHDL 1076 2000, Edícia) 2002 Revízia štandardu (pomenovaný VHDL 1076-2002) 2007 VHDL Procedural Language Application Interface standard (VHDL 1076c-2007) 2009 Revízia štandardu (pomenovaný VHDL 1076-2008) Verilog Verilog [12] opisný hardvérový jazyk. Ide o textový formát pre popis elektronických obvodov a systémov. Verilog sa používa pri elektronickom návrhu, napríklad pre overenie pomocou simulácie, časovú analýzu a logickú syntézu. Dôležité je, že VHDL nie je skratka pre Verilog HDL. Verilog a VHDL sú dva odlišné HDL jazyky, avšak majú veľa spoločného. História Verilog HDL siaha až do roku 1980, kedy spoločnosť s názvom Gateway Design Automation vyvinula logický simulátor, Verilog-XL, a spolu s ím jazyk pre popis hardvéru. Cadence Design Systems získala Gateway v roku 1989 a spolu s ním aj práva na jazyk a simulátor. V roku 1990, Cadence poskytol jazyku (nie však simulátor) do verejnej sféry s úmyslom štandardizovania jazyka. Verilog HDL teraz spravuje nezisková organizácia Accellera, ktorá vznikla zlúčením Open Verilog International (OVI) a VHDL International. OVI mal za úlohu štandardizovať jazyk do IEEE. História Verilog HDL siaha až do roku 1980, kedy spoločnosť s názvom Gateway Design Automation vyvinula logiky simulátor, Verilog-XL, a spolu s ním jazyk pre popis hardvéru. Cadence Design Systems získala Gateway v roku 1989 a spolu s ním aj práva na jazyk a simulátor. V roku 1990, Cadence poskytol jazyku (nie však simulátor) do verejnej sféry s úmyslom štandardizovania jazyka. Verilog HDL teraz spravuje nezisková organizácia Accellera, ktorý vznikla zlúčením Open Verilog International (OVI) a VHDL International. OVI mal za úlohu štandardizovať jazyk do IEEE. Verilog HDL sa stal štandardom IEEE v roku 1995 pod číslom 1364. Revidovaná ver- 13
zia bola uverejnená v roku 2001, čo je najčastejšie používaná verzia Verilogu. IEEE Verilog štandardný dokument je známy ako referenčná príručka jazyka, alebo LRM (Language Reference Manual). ďalšie revízia Verilogu bola uverejnená v roku 2005. SystemVerilog je obsahuje obrovskú sadu rozšírení Verilogu a bol prvýkrát vydaný ako štandard IEEE v roku 2005. IEEE 1364 taktiež definuje Programovací jazyk rozhrania, alebo PLI (Programming Language Interface). Je to kolekcia programov a rutín, ktoré umožňujú obojsmerné rozhranie medzi Verilogom a inými jazykmi (najčastejšie C). 1.4 Zhrnutie analýzy Analýza je venovaná základným hodnotiacim systémom. Bola spomenutá stručná história vývoja týchto systémov a popis jednotlivých generácií. Pri každej generácii boli zdôraznené hlavné črty a inovácie tej ktorej generácie. Zároveň bolo popísaných niekoľko najúspešnejších systémov z každej generácie z hľadiska funkcionality a inovácií, ktoré daný systém priniesol. V ďalšej časti analýzy bol rozobratý všeobecný algoritmus na porovnávanie reťazcov. Podrobne je popísaný každý krok, ktorý je nutné vykonať k zisteniu tzv. indexu podobnosti, teda nakoľko sa porovnávané reťazce podobajú. Tento algoritmus bude modifikovaný pre potreby navrhovanej aplikácie. V poslednej časti analýzy je stručne popísaný jazyk HDL, na ktorý bude navrhovaná aplikácia špecializovaná. 14
Návrh V tejto kapitole bude uvedený návrh samotného systému a algoritmu hodnotenia. Tento návrh vychádza z kapitoly Analýza a z poznatkov v nej získaných. Prvotná idea vytvorenia tohto systému je absencia modulu na vyhodnocovanie zadaní do už existujúcich systémov, ktoré sa používajú na fakulte. Hlavným prínosom bude možnosť hodnotiť programy napísané študentmi tak, aby bolo hodnotenie čo najviac podobné hodnoteniu učiteľa. Cieľom návrhu však nebude implementácia tohto modulu do týchto systémov, len návrh samotných algoritmov na spracovanie a ohodnotenie programov. 2.1 Špecifikácia požiadaviek Po analýze problematickej oblasti vyplynuli tieto požiadavky na navrhovaný systém: jednoduché užívateľské rozhranie Systém musí mať intuitívne a ľahko naučiteľné rozhranie. Všetky ovládacie prvky musia byť jednoducho prístupné a užívateľ musí z rozhrania vždy vedieť, v ktorom kroku sa práve nachádza. vstupné súbory v jazyku VHDL Vstupným súborom sa rozumie vzorové riešenie a kód odovzdaný študentom. Súbory môžu byť priamo vo vhdl formáte, no môžu sa použiť aj obyčajné textové súbory čí HTML stránky. jednoznačne zadané štruktúra vzorového riešenia Aby bolo hodnotenie čo najefektívnejšie, je potrebné aby učiteľ nastavil štruktúru riešenia, teda pomocou akých príkazových štruktúr je vzorové riešenie urobené, teda ako má študent postupovať pri písaní zadania. presne udané parametre hodnotenia Učiteľ musí jednoznačne určiť maximálny počet bodov, ktoré môže študent získať, nastaviť stupnicu, či nastaviť postihy za chyby v kóde. 15
presne definovaný výstup programu Výsledky hodnotenia sa zobrazia priamo v okne programu, alebo sa uložia do externého súboru, ktorý určí učiteľ. 2.2 Návrh samotného systému Systém ako taký bude veľmi jednoduchý z hľadiska používania. Dôvodom je to, že tento systém je určený len pre učiteľa. Z toho vyplýva, že k systému bude naraz pristupovať len jeden používateľ. Odpadá teda nutnosť návrhu rozhrania pre viacero užívateľov. V súčasnej dobe sa na fakulte používajú dva systémy na hodnotenie. Prvý je modul v systéme Moodle, ktorý sa volá Drag-and-drop test, alebo sa tiež nazýva Chyťaposunovka. Študent dostane zadanie úlohy a neúplný kód. Ďalej má k dispozícii sadu príkazov, ktoré vkladá na prázdne miesta v kóde. Hodnotenie spočíva v zistení, či sa na danom riadku nachádza správny príkaz, alebo nie. Ak áno, pridelí sa bod. Z tohto jasne vyplývajú isté problémy. Ak sa napríklad správna postupnosť príkazov posunie o riadok, všetky tieto riadky budú označené ako nesprávne. Tiež sa môže stať, že študent zabudne vložiť jeden príkaz. To znamená, že všetky príkazy pod chýbajúcim príkazcom budú posunuté hore a ohodnotia sa ako nesprávne. Druhý systém je písanie zadaní na tzv. tabletoch. Študent má k dispozícii text zadania a definovanú základnú entitu programu. Následné riešenie je potom prenechané na študentovi. Výsledný kód je prenesený na server, kde je skompilovaný a spustený s testovacou sadou signálov. Ak sa výsledky zhodujú s referenčnými výsledkami, študent dostane plný počet bodov. Ak sa výstupné signály nezhodujú s referenčnými, nastáva bodový postih pri každej nezhode. Napríklad, ak sa líši v jednom okamihu súbor ôsmich signálov o dve hodnoty, berie sa to ako 2 chyby, čiže 1/4 z bodu a podobne. Výhoda systému Chyťaposunovky spočíva v tom, že je presne zadané vzorové riešenie, teda sa značne zjednoduší porovnávanie kódu študenta oproti vzoru. Pri tabletoch je situácia horšia. Keďže študent má voľnosť pri riešení, daný problém môže opísať niekoľkými spôsobmi. Tento problém sa môže z časti vyriešiť tým, že sa študentovi zadá, ktorý typ príkazu má požiť pri riešení. Celý systém bude pracovať nasledovne: výber hodnotiaceho modulu nastavenie parametrov hodnotenia načítanie kódu napísaného študentom a vzorového riešenia 16
transformácia zdrojového kódu porovnanie kódu so vzorkou ohodnotenie zadania výpis hodnotenia, prípadne počet a výskyt chýb v kóde Celý postup ohodnotenia teda funguje takto. Prvý krok bude výber hodnotiaceho modulu, čo znamená, či sa budú kontrolovať zadania z Chyťaposunovky, alebo z Tabletov. Tento výber ovplyvní časť normalizácie kódu. Pri Chyťaposunovke totiž stačí len základná úprava reťazcov, teda odstránenie zbytočných medzier a transformácia na malé písmená. Pri tabletoch treba navyše premenovať všetky signály a premenné a tiež normalizovať konštrukcie IF alebo CASE. Ďalej treba nastaviť, či daný kód obsahuje určitú štruktúru, alebo bude riešenie ponechané na študentovi. Pokiaľ bude striktne zadané, že študent má použiť len jeden možný typ konštrukcie, celý proces analyzovania kódu sa značne zjednoduší. Pokiaľ však nebude presne daná forma zadania, bude treba kód porovnať s viacerými možnými riešeniami, tzv. vzorkami. Pokračuje sa nastavím parametrov hodnotenia. Určí sa počet bodov, ktoré môže študent získať za zadanie. Ďalej sa nastavia postihy za chyby v kóde. Ak sa v kóde vyskytnú rozdiely oproti referenčnému príkladu, počet týchto chýb sa zistí a podľa nastavenej stupnice postihov sa strhnú body. Učiteľ pripraví vzorové riešenie alebo vzorky, podľa ktorých sa bude študentov zdrojový kód testovať. Súbor s riešením alebo vzorkami sa načíta do programu. Následne sa načíta študentov zdrojový súbor. Princíp analýzy kódu spočíva v normalizácii kódu podľa výberu v prvom kroku. Po tejto úprave sa kód porovná so vzorom a zistí sa počet chýb. Na základe nastavenej stupnice postihov sa určí konečný bodový zisk. Nakoniec sa zobrazia výsledky. Buď v okne programu, alebo budú poskytnuté vo výstupnom súbore. Učiteľ môže samozrejme hodnotenie upraviť na základe jeho subjektívneho názoru. Celý postup hodnotenia je zobrazený na obrázku 2.1 2.2.1 Porovnávací algoritmus Základný kameň celého systému je porovnávacia časť. Predom upravený kód, či už žiakov alebo vzorové riešenie, sa musia spolu porovnať. Výsledkom porovnania je počet nezhôd, ktorý je prepočítaný na výsledný bodový zisk. Pri vytváraní porovnávacieho algoritmu som sa zo značnej časti inšpiroval jedným riešením, ktoré som našiel na internete [13]. Je to jednoduchý porovnávací algoritmus, ktorý porovnáva dva textové súbory. Výsledkom je potom HTML súbor, ktorý zobrazí na jednej stránke oba porovnávané súbory, vyznačí, čo je oproti vzorovému súboru zmenené, pridané, zmazané a čo je rovnaké. Porovnávanie sa vykonáva po 17
Obr. 2.1: Postup hodnotenia riadkoch. Keďže som nechcel veľmi zasahovať do kódu porovnávacieho algoritmu, bolo treba pripraviť oba súbory tak, aby bol použitý algoritmus čo najefektívnejší. Uvažoval som teda, či porovnávať celý kód naraz, alebo jeho časti osobitne. Z hľadiska implementácie by bol prvý prístup jednoduchší. Po zvážení všetkých možných situácií a stavov, ktoré môžu nastať pri porovnávaní som sa rozhodol, že ošetrovanie týchto stavov by bolo veľmi náročné. Preto sa bude porovnávanie vykonávať pre jednotlivé časti kódu osobitne. Konkrétne sa jedná o definície entít, popisy procesov a s nimi súvisiace konštrukcie IF a CASE. 2.2.2 Hodnotiaci algoritmus Hodnotiaci algoritmus bude fungovať na princípe postupnej transformácie kódu, ktorý odovzdá študent na vzorový kód. Podľa počtu zmien pri transformácii kódu sa študen- 18
tovi strhnú body. Učiteľ nastaví maximálny počet bodov, ktoré môže študent získať a jednotlivé váhy postihov k daným typom chýb. Ak sa napríklad bude v zadaní vyskytovať len jedna konštrukcia CASE, bodový postih za každú chybu bude väčší ako pri zložitejšom kóde, kde bude postih menší. Výstupom z hodnotenia bude potom percentuálna úspešnosť žiaka, ktorá sa môže prepočítať na počet bodov, zaokrúhlený podľa nastavenia učiteľa. 2.2.3 Popis rozhrania Rozhranie bude veľmi jednoduché. Bude ponúkať túto základnú funkcionalitu: vybrať hodnotiaci modul Keďže systém pracuje so súbormi z dvoch rôznych systémov, pričom postup hodnotenia sa mierne líši v závislosti od vybraného systému, je nutné aby učiteľ vybral správny modul. načítať zdrojové súbory, ktoré sa budú kontrolovať a hodnotiť Učiteľ zadá cestu k súborom, alebo vyberie súbory pomocou dialógového okna. Podmienkou správneho fungovania pri module Chyťaposunovka je nahrať vzorový súbor s vyznačenými poliami, ktoré žiak v Chyťaposunovke musí doplniť. Ako študentov kód sa môže použiť textový súbor skopírovaný z Chyťaposunovky, alebo priamo HTML export danej stránky, na ktorej sa kód nachádza. V prípade modulu Tablety nie je v podstate žiadne obmedzenie na vstupné súbory. nastaviť parametre formátu vstupného súboru Pri module Chyťaposunovka nie je žiadne obmedzenie na nastavenie formátu požadovaného kódu, keďže je riešenie jednoznačne dané. Pri tabletoch je potrebné nastaviť, aké konštrukcie sa požadujú od študenta pri riešení. Ak študent nedodrží požadovaný formát kódu, nebude možné ohodnotiť jeho zadanie správne. nastaviť parametre hodnotenia a postihov Učiteľ nastaví maximálny počet bodov a postihy za jednotlivé chyby. zobraziť výsledky na obrazovke Zobrazenie výsledkov hodnotenia sa vykoná v okne programu. Zobrazí sa percentuálna úspešnosť, alebo počet získaných bodov. Taktiež sa zobrazia chyby, ktoré študent urobil. export výsledkov do súboru Výsledky sa môžu tiež nahrať do textového súboru, ktorý sa uloží na miesto ktoré určí učiteľ. 19
2.2.4 Návrh pre paralelné spracovanie Návrh paralelného spracovania pre navrhovaný systém sa môže uberať dvoma smermi. Prvým je rozdeliť celý proces hodnotenia medzi viacero počítačov alebo procesorov, no takýto postup je veľmi náročný na synchronizáciu a celkové využívanie zdrojov pri takomto druhu paralelného spracovania. Druhý prístup spočíva v načítaní viacerých zdrojových kódov od študentov, a následné spustenie na viacerých počítačov tak, že každý počítač spracováva práve jedno zadanie. Týmto sa urýchli celý proces hodnotenia pričom sa vôbec nemusí zasahovať do algoritmov. Stačí, ak sa naprogramuje modul o úroveň vyššie, ktorý by dokázal spravovať jednotlivé inštancie systému, posielať mu súbory a zbierať a triediť získané dáta. 20
Implementácia V tejto kapitole je opísaný postup implementácie, implementačné prostredie a popis základných funkcií programu. 3.1 Implementačné prostredie Aplikácia je implementovaná v jazyku C++ s knižnicami MFC. Vyvíjala sa v prostredí VisalStudio 2005 od firmy Microsoft. Knižnice MFC sú v operačnom systéme Windows XP a vyššom štandardne implementované, nebude teda problém spustiť aplikáciu na týchto systémoch. Pri implementácii sa uvažovalo aj na použitím platformy Java, no pri budúcom zakomponovaní aplikácie do existujúcich systémov na hodnotenie, ktoré sa momentálne používajú na fakulte by nastal problém, nakoľko sú písané v jazyku C++, alebo C#. 3.2 Popis implementácie Najväčšiu časť zdrojového kódu zaberá porovnávací algoritmus. Ako bolo spomenuté, je inšpirovaný jedným riešením z internetu [13]. Kód som upravil pre moje potreby. Pôvodne algoritmus zvládal porovnávať aj na základe veľkosti písmen a podľa odsadenia, no pre moje účely bola táto funkcionalita úplne zbytočná. Ďalej je upravený aj samotný vyhodnocovací algoritmus. Popísaný je v časti návrh. Pri implementácii modulu pre tablety som ale narazil na problém s refaktorizáciou kódu. Možnosti, ktorými môže študent opísať svoje riešenie je veľmi veľa, preto sa mi nepodarilo pokryť všetky možné kombinácie. Toto obmedzenie sa dá eliminovať zadaním presného formátu kódu, názvov premenných a signálov. V budúcnosti sa samozrejme dá táto chýbajúca funkcionalita doplniť. Podrobný popis implementácie sa nachádza na elektronickom médii. Technická dokumentácia je generovaná pomocou nástroja Doxygen. 21
Zhodnotenie Automatické hodnotenie žiakov zaznamenalo v posledných rokoch veľký rozmach. V podstate každá lepšia škola sa snaží buď používať, alebo dokonca sama vyvíjať systémy, ktoré by dokázali efektívne ohodnotiť prácu študentov a týmto napomôcť nielen učiteľovi, ale aj samotným študentom. Dobre použitý systém na hodnotenie totiž môže mať priaznivý vplyv na úroveň vzdelávania. Náplňou tejto práce bolo vytvorenie systému automatického hodnotenia HDL modelov. V prvej časti práce som stručne opísal existujúce riešenia a časť algoritmov, ktoré používajú pri hodnotení. Načrtol som tiež stručnú históriu a verzie jazyka HDL. Poznatky z analýzy boli potom pretavené do špecifikácie požiadaviek na navrhovaný systém hodnotenia. Tie požiadavky boli časom rozšírené a transformované na celkový návrh systému. Celý proces vývoja bol orientovaný na použitie v kooperácii s existujúcimi riešeniami na fakulte. Týmito systémami sú Chyťaposunovka, čo je testovací modul v systéme Moodle a tzv. Tablety. Pri implementácii došlo k určitým obmedzeniam oproti návrhu. Prvým obmedzením je nutnosť presne určeného formátu vzorového súboru a súborov od žiakov. Vyplynulo to z rôznorodosti spôsobov riešení daného problému. Ďalším problémom bol formát súborov z Chyťaposunovky. Tento systém totiž nemá nijakým spôsobom implementovaný export výsledkov a žiakovho kódu. Jediná možnosť, ako získať tieto dáta je skopírovanie textu riešenia do textového súboru zo stránky s riešením, alebo priame použitie HTML stránky stiahnutej zo systému Moodle. Obe možnosti sú funkčné a je na učiteľovi, ktorý typ si vyberie. Na vzorový súbor je tiež kladená jedna podmienka a to potreba vyznačenia polí, ktoré študent dopĺňa. Problém paralelného spracovania je stručne opísaný v časti návrhu. Táto časť nie je implementovaná, pretože na počiatočné potreby použitia tohto systému nie je nutná. Navyše som nemal k dispozícii vhodný cluster, kde by sa dalo riešenie testovať. Výsledkom práce je teda implementovaný systém na hodnotenie žiakov, podľa požiadaviek zadania. 22
4.1 Možnosti zlepšenia systému podpora viacerých programovacích jazykov zakomponovanie systému priamo do používaných systémov na fakulte prepracovanie refaktorovacej logiky vylepšenie použitých algoritmov implementácia v paralelnom prostredí 23
Literatúra [1] MALMI L. et al.: Experiences on automatically assessed algorithmic exercises. ACM J. Edu.Resources Comput, 2006, s. 1-2. [2] DOUCE, Ch.: Automatic Test-Based Assessment of Programming: A Review. ACM Journal of Educational Resources in Computing, Vol. 5, No. 2, 2005, s. 1-6. [3] HIGGINS, C. A. et al: Automated Assessment and Experiences of Teaching Programming. ACM Journal of Educational Resources in Computing, Vol. 5, No. 3, 2005. [4] HOLLINGSWORTH, J.: Automatic graders for programming classes. Commun. ACM 3, 10, 1960, s. 528-529. [5] JAYAL, A., SHEPPERD, M.: An Improved Method for Label Matching in e- assessment of Diagrams. ITALICS Volume 8 Issue 1, 2009, s. 5-9. [6] REEK, K. A.: The TRY system - or - how to avoid testing student programs. SIGCSE Bull. 21, 1, 1989, s. 112-116. [7] VON MATT, U.: Kassandra: The automatic grading system. Tech. Rep.UMIACS- TR-94-59, Institute for Advanced Computer Studies, Dept. of Computer Science, University of Maryland, 1994. [8] JACKSON, D., USHER, M.: Grading student programing using ASSYST. In Technical Symposium on Computer Science Education, Proceedings of the 28th SIGCSE (San Jose, CA), 1997, s. 335-339. [9] HIGGINS, C. et al: The CourseMaster CBA system: Improvements over Ceilidh. J. Edu. Inf.Technol. 8, 3, 2003, s. 287-304. [10] http://www.economicexpert.com/a/hardware:description:language.html, 9. 5. 2010. [11] Doulos. 2009. The Designer s Guide to VHDL http://www.doulos.com/knowhow/vhdl_designers_guide/, 9. 5. 2010. 24
[12] Doulos. 2009. Verilog Designer s Guide http://www.doulos.com/knowhow/verilog_designers_guide/, 9. 5. 2010. [13] RODRIGEEZ, S.: Diff Tool. 2002 http://www.codeproject.com/kb/applications/difftool.aspx, 9. 5. 2010. 25
Príloha A Technická dokumentácia A.1 Popis zdrojových súborov Celé riešenie je v jednom projekte prostredia VisualStudio 2005. Súbory sú rozdelené na hlavičkové a zdrojové. Hlavičkové súbory v sebe obsahujú deklarácie tried, ich premenných, metód a vlastností. Zdrojové súbory potom tieto triedy využívajú pri práci so zadaniami. Súbor bcdiffdlg.cpp má na starosti získanie ciest k súborom, ktoré sa majú hodnotiť a následne odoslať tieto cesty hodnotiacemu algoritmu. Súbor bcdiff.cpp overí, či sú cesty k súborom správne a či súbory existujú. Ďalej súbory predpripraví a následne na ne spustí porovnávací algoritmus. Ten pracuje tak, že sa snaží pretransformovať študentov kód do rovnakej formy, ako má vzorové riešenie. Každá zmena je postihnutá bodovou stratou nastavenou pred spustením hodnotenia. Nakoniec sa zavolá dialógové okno s výsledkami. Súbor fileparticion.cpp ukladá súbory v špeciálnej štruktúre. Pri vytváraní obrazu súboru sa volá funkcia PreProcess(CString szfilename, int type). Táto funkcia zabezpečí normalizáciu kódu a prevod súboru riadok po riadku na tzv. tokeny, teda vyráta sa číselná hodnota reťazca. Pre porovnávanie je totiž porovnanie dvoch čísel rýchlejšie ako porovnávanie reťazcov. Všetky tokeny sú uložené do poľa tokenov v poradí, v akom nasledovali riadky v súbore. Popri tom sa uchováva aj informácia o reťazci každého riadku. Súbor DiffEngine.cpp je súbor z pôvodného projektu, podľa ktorého je celý porovnávací algoritmus inšpirovaný. Jeho funkcionalita spočíva v tom, že vykoná klasický diff algoritmus a výsledky zobrazí v HTML stránke. Na ľavej strane výpisu je pôvodný súbor, na pravej novší súbor. Tento algoritmus tiež zvýrazňuje riadku, ktoré boli pridané, zmazané, alebo zmenené. Túto funkcionalitu som v projekte ponechal preto, lebo po malej úprave kódu poskytuje možnosť zobraziť celý postup transformácie študentovho kódu na vzorový v prehľadnej HTML stránke. Navyše je zviazaná so 26
štruktúrou predpripravených súborov a dobre s ním pracuje. A.2 Používateľská príručka Používanie systému je veľmi jednoduché. Nie je potrebná žiadna inštalácia, systém sa jednoducho spustí súborom.exe. Prostredie ponúka len najnutnejšie nastavovacie prvky. Konkrétne sa jedná o 2 polia pre cestu k súboru, jedno pre vzor, jedno pre študentov kód. Ďalej sa tu nachádza výber modulu, z ktorého sú súbory exportované. Pri Chyťaposunovke je ďalej možnosť nastaviť, či je študentov kód kopírovaný do textového súboru, alebo či je exportovaný ako HTML stránka. V posledom rade sa dajú nastaviť parametre hodnotenia. A to maximálny počet bodov, a jednotlivé postihy. Celé dialógové okno je zobrazené na obrázku A.1. Výsledok hodnotenia je zobrazený v malom modálnom okne. Poskytuje informácie o počte získaných bodov a o počte bodov strhnutých za jednotlivé postihy. Okno je zobrazené na obrázku A.2. Obr. A.1: Hlavné okno systému Obr. A.2: Výsledky hodnotenia 27