U P O R A B N A I N F O R M A T I K A38 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko, Koroška cesta 46, 2000 Maribor ales.cep@um.si, damijan.novak@um.si, jani.dugonik@um.si Samodejno preverjanje pravilnosti študentskih nalog iz programiranja Izvleček Fakultete se lahko soočijo s problematiko preverjanja pravilnosti delovanja velikega števila oddanih nalog, predvsem pri predmetih iz programiranja. Predlagan sistem za avtomatizacijo preverjanja oddanih nalog lahko čas testiranja nalog bistveno skrajša in s tem razbremeni pedagoško osebje. Povratne informacije o točnosti oddane naloge so deležni tudi študenti, ki jim sistem poda opis na- pake, ki jo lahko v ponovnem poskusu oddaje odpravijo. Sistem omogoča preverjanje nalog v dveh programskih jezikih (C# in C++), komunikacija med pedagogom in študentom pa spada v kategorijo e-učenja. Prednost uporabe predlaganega sistema je popolna nepristranost ocenjevalca, slabost pa se kaže v večjem začetnem časovnem vložku, potrebnem za sestavo naloge. V članku bo po- drobneje predstavljena notranja zgradba sistema za preverjanje pravilnosti delovanja nalog iz programiranja. Ključne besede: Docker, e-učenje, Moss, ocenjevanje študentskih nalog, testiranje enot, testno voden razvoj. Abstract Faculties may face the problem of verification of many submitted assignments, especially in subjects with programming assi- gnments. The proposed system for verification automation of submitted assignments can significantly reduce the testing times and relieve the teaching staff. Feedback about the submitted assignments’ correctness is also given to the students, as well as descrip- tions of the errors so that they can correct the assignments and submit them again. The system supports the verification for two different programming languages (C# and C++). The communication between the teacher and the student puts the proposed sy- stem into the E-learning category. The advantage of using the proposed system is the complete impartiality of the assessor while the disadvantage is that more time is needed to compose an assignment. This paper presents the detailed internal structure of the assignment verification system. Keywords: Docker, e-learning, grading of the student assignments, Moss, Test Driven Development, Unit testing. 1 UvoD Pri predmetih iz programiranja se študente seznani s pravilno sintakso in uporabo specifičnih program- skih jezikov, s pristopi sestavljanja postopkov oz. al- goritmov ter s predstavitvijo podatkov in podatko- vnih struktur. Na fakultetah pri predmetih z večjim številom štu- dentov (več kot 100) predstavlja preverjanje oddanih nalog velik izziv tako z vidika zagotavljanja enakega kriterija ocenjevanja kot tudi časovne obremenitve pedagoškega osebja. Zaradi teh razlogov smo se od- ločili za avtomatizacijo postopka preverjanja študent- skih nalog, ki se že nekaj let uporablja na Fakulteti za elektrotehniko, računalništvo in informatiko. Sistem se uporablja pri predmetu Podatkovne strukture v 1. letniku visokošolskega študija, na dveh študijskih smereh (računalništvo in informatika), kjer je v po- sameznem študijskem letu skupno vpisanih več kot 200 študentov. Študentje lahko izbirajo med dvema programskima jezikoma: C# in C++. Pri vsaki nalogi so na voljo navodila in predloga programa, ki vsebuje vnaprej deklarirane razrede, programske strukture ter metode. Metode, ki jih morajo implementirati študenti na osnovi podanih navodil, so podane samo s prototipi in komentarji z razlago. Od samega začetka je bil sistem zasnovan z mis- lijo na vpetost študentov v učni proces in na njihovo uporabniško izkušnjo. Če študent pri implement- StrOkOVNI prISpEVEk U P O R A B N A I N F O R M A T I K A 392020 - πtevilka 1 - letnik XXVIII aciji sledi navodilom naloge, mu sistem ob morebitni storjeni napaki pri osvajanju zahtevane snovi ozi- roma opravljanju naloge poda jasen povraten odziv. Pedagog in študent sta tako aktivno vključena v pre- pletenost učnega procesa in Informacijsko-Komu- nikacijske Tehnologije (IKT) sistema, kar na kratko imenujemo e-učenje. Predlagan sistem nadaljuje razvoj sistema za preverjanje pravilnosti študentskih nalog (Zeml- jak, Novak, Čep, & Verber, 2016). Glavni napredek je storjen v stopnji avtomatizacije s prenosom nalog s spletne učilnice in pri sestavljanju razpredelnice z odzivi, kar pohitri objavo rezultatov. Prav tako smo v sistem dodali zabojnike Docker, s čimer smo poskr- beli za dodatno izolacijo med izvajanjem testov. Za preverjanje podobnosti izvorne kode smo dodali up- orabo sistema Moss. Preostanek članka je organiziran na naslednji način. Poglavje 2 opiše področja in orodja, uporablje- na v našem sistemu. Poglavje 3 predstavi sorodne sis- teme s področja računalniškega popravljanja nalog. Predlagan sistem je opisan v poglavju 4. Poglavje 5 vsebuje predstavitev primera ogrodja in testne me- tode. Poglavje 6 vsebuje zaključek članka. 2 PReDSTAVITeV PODROčJA V tem poglavju predstavljamo področja, ki so ključna za razumevanje delovanja sistema in so pomembna za njegovo gradnjo oziroma izvajanje. Najprej opre- delimo definicijo e-učenja kot ključno kategorijo, v katero se umešča ta sistem. Nato opišemo testno voden razvoj in testiranje enot, ki imata ključno vlogo pri gradnji nalog in njihovem preverjanju. V sistemu platforma Docker poskrbi za izolacijo tes- tov med izvajanjem, sistem Moss pa je uporabljen za preverjanje podobnosti programske kode z na- menom preprečevanja plagiatorstva. 2.1 e-učenje Zgodovinsko gledano ima e-učenje oziroma e-izobraževanje (angl. E-Learning) korenine v učenju na daljavo. Z nastankom interneta je namreč postalo mogoče, da sta pedagog in učenec ločena krajevno in prostorsko, med njima pa poteka komunikacija (E-izobraževanje - Wikipedija, prosta enciklopedi- ja, 2019). Pri tem ne gre samo za deljenje gradiv v elektronski obliki, v smislu izmenjave preprostih elektronskih sporočil, ampak se e-učenje definira kot pedagogika (umetnost in znanost učinkovitega učenja), ki je še dodatno obogatena s sodobno IKT. E-učenje je tako povezava med IKT in učenjem, vodilno mesto v tej povezavi pa pripada pedagogiki. IKT mora biti zanesljiva in dovolj preprosta za upo- rabo, da ne moti učnega procesa (Nichols, 2007). Dandanes se v pojem e-učenja vključujejo:  učenje na daljavo (ni samo v spletni obliki, npr. DVD z naloženo vsebino za učenje),  mešani načini deljenja virov (npr. spletni viri do- polnjujejo učenje v učilnici),  spletno učenje (celotna komunikacija poteka iz- ključno preko spleta),  interaktivnost vsebin (od preprostih povezav na spletne strani do učnih okolij, ki so popolnoma prilagojena uporabniku),  sistemi za nadzor učenja (z vključenimi možnost- mi ocenjevanja) in  pedagogika. 2.2. Testno voden razvoj Testno voden razvoj (angl. Test-Driven Development − TDD) je metodologija, ki s pomočjo zelo kratkih raz- vojnih ciklov omogoča razvoj programskih in infor- macijskih rešitev, kar jo uvršča med agilno-iterativne procese. Razvoj poteka tako, da se v posameznem ciklu najprej napiše specifična testna metoda (oz. test), šele nato se izvede implementacija funkcional- nosti (oz. dela specifikacij sistema, ki ga razvijamo). Testna metoda tako vodi proces razvoja implemen- tacije funkcionalnosti. Cikel je zaključen, ko se test izvede pravilno, implementacija funkcionalnosti pa je ustrezno vključena v rešitev. Za posamezno funk- cionalnost se lahko ponovi več ciklov. Testi morajo biti spisani tako, da jih odlikujejo lastnosti, kot so: neodvisnost, razumljivost in hitrost. 2.3. Testiranje enot Testiranje enot (angl. Unit testing) (Myers, Sandler, & Badgett, 2011) je metoda testiranja programske kode, pri kateri se testi izvajajo na nivoju posamezne enote (npr. metode, funkcije ali razreda) v progra- mu. Pri pisanju testov je najpogosteje v uporabi t. i. AAA (angl. Arrange-Act-Assert) vzorec, ki predlaga razdelitev testne metode na tri stopnje:  urejanje (angl. Arrange) – začetna stopnja, kjer se pripravijo vhodni podatki za testirano enoto in določi pričakovan izhod,  izvajanje (angl. Act) – klic testirane enote s pripra- vljenimi vhodnimi podatki, Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja U P O R A B N A I N F O R M A T I K A40 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja  potrjevanje (angl. Assert) – končna stopnja, kjer se izvede primerjava med dobljenim izhodom iz te- stirane enote ter predvidenim izhodom iz začetne stopnje. 2.4. Platforma Docker Platforma Docker (Docker Inc., 2019; Gradišnik & Ma- jer, 2016) je odprtokodna platforma za razvoj aplikacij, njihovo distribucijo in zagon na različnih infrastruktu- rah z uporabo t. i. zabojnikov. Zabojnik Docker (angl. Docker container) temelji na tehnologiji zabojnikov iz operacijskega sistema Linux in predstavlja nivo abstrakcije na aplikacijskem nivoju. Njegov namen je izolacija programske opreme od izvajalnega sis- tema. Znotraj zabojnika se zažene slika Docker (angl. Docker image), ki je izvedljiv paket z vsem potrebnim za zagon aplikacije − izvajalno kodo, datotečnim sist- emom in vsemi potrebnimi knjižnicami. 2.5. Sistem moss Kot pomoč pri odkrivanju plagiatov uporabljamo sistem za določanje podobnosti programske kode, imenovan Moss (Aiken, 2018) (angl. Measure Of Software Similarity). Algoritem, uporabljen za odkri- vanje prevar v sistemu Moss, v primerjavi z drugimi podobnimi algoritmi dosega veliko boljše rezultate (Bowyer & Hall, 1999). Sistemu posredujemo seznam programskih kod, ki jih želimo medsebojno primer- jati, ta pa nam kot rezultat vrne datoteko HTML s poudarjenimi deli programskih kod, ki nakazujejo podobnost, in odstotke podobnosti. Dodatna funkcionalnost sistema je možnost od- stranjevanja t. i. lažnih ujemanj, saj se iz primerjave odstrani t. i. skupna programska koda (npr. knji- žnice, že napisana programska koda itd.). Sistem Moss trenutno podpira več programskih jezikov: C, C++, Java, C#, Python, Visual Basic, Javascript, FOR- TRAN, ML, Haskell, Lisp, Scheme, Pascal, Modula2, Ada, Perl, TCL, Matlab, VHDL, Verilog, Spice, MIPS assembly, a8086 assembly, a8086 assembly in HCL2. Ker sistem Moss poda zgolj odstotek ujemanja posameznih programskih kod, ni namenjen popol- noma avtomatiziranemu odkrivanju plagiatorstva, temveč pregledovalcu služi zgolj kot pripomoček. 3 SoroDne iDeje Računalniško preverjanje, vrednotenje in ocenje- vanje nalog iz programiranja je staro skoraj toliko kot programiranje samo. Sisteme preverjanja nalog iz programiranja delimo glede na (Ihantola, Aho- niemi, Karavirta, & Seppälä, 2010; Romli, Sulaiman, & Zamli, 2010): stopnjo sposobnosti samodejnega preverjanja, število podprtih programskih jezikov, izvajalno okolje preverjanih programov itd. Upora- bljeni so na različnih institucijah (Auffarth, López- -Sánchez, Campos i Miralles, & Puig, 2008; Edwards, 2003), kamor moramo prišteti tudi aktualne spletne akademije (Massive open online course - Wikipedia, 2019). Primer takšnih so Coursera (Coursera Inc., 2019), edX (edX Inc., 2019), Udemy (Udemy, Inc., 2019), LinkedIn Business (LinkedIn Learning, 2019), Udacity (Udacity, Inc., 2019) itd., ki so namenjene skoraj neomejenim številom udeležencem. Večina spletnih akademij poleg tradicionalnih gradiv (pos- neta predavanja, branje, množica problemov) ponuja interaktivne tečaje z uporabniškimi forumi, ki pod- pirajo interakcijo med študenti, učitelji in asistenti, omogočajo pa tudi takojšne povratne informacije za kvize in naloge. Za podrobnejši pregled orodij za samodejno preverjanje nalog vestnemu bralcu svetu- jemo ogled dodatne literature (Douce, Livingstone, & Orwell, 2005). V literaturi (Zeller, 2000) je predstavljen sistem Praktomat, ki študentom omogoča medsebojno pregledovanje in ocenjevanje programov z namenom izboljšanja kakovosti ter sloga programske kode. Študent ima po oddani svoji nalogi možnost prido- biti nalogo drugega študenta, ki jo nato pregleda. Po pregledu študent dobi povratno informacijo o oddaji svoje naloge in možnost ponovne, popravljene odda- je. Sistem pregledovanja je neodvisen od ocenjevanja. Možnost plagiatorstva je zmanjšana s poosebljenimi nalogami in samodejnim testiranjem oddanih nalog. 4 PReDSTAVITeV NAŠegA SISTemA Predstavljen sistem nadaljuje delo predstavljeno v (Zemljak, Novak, Čep, & Verber, 2016). Omogo- ča preverjanje oddaj študentskih nalog z namenom dviga kakovosti študijskega procesa, saj gre za ne- pristranost (objektivnost preverjanja pravilnosti pro- gramske kode), hitrejše preverjanje študentskega razumevanja učne snovi ter poenotene odzive, ki jih študentje dobijo po oddaji naloge. Poenoteni odzivi študentom ponudijo večjo jasnost pri razumevanju lastnih lukenj v znanju, hkrati pa se jim zagotovi hi- trejša in bolj strukturirana pomoč pri odpravi more- bitnih napak. Prednost sistema je tudi razbremenitev pedagoškega osebja, saj čas preverjanja nalog ne ra- U P O R A B N A I N F O R M A T I K A 412020 - πtevilka 1 - letnik XXVIII ste več linearno s količino oddaj. Treba je pa vzeti v zakup, da je začetna priprava naloge za samodejno preverjanje časovno daljša in je potreben razmislek, ali je uporaba takšnega sistema časovno upravičena pri manjšem številu oddanih nalog. Delovanje sistema za preverjanje študentskih oddaj je razdeljeno v šest faz: 1. začetna priprava naloge, 2. izdelava in objava predloge, vključno z navodili, 3. prenos in razvrščanje oddanih nalog, 4. preverjanje plagiatorstva, 5. obdelava in testiranje nalog, 6. objava rezultatov. Prva faza je opravljena s strani upravljavcev siste- ma in vključuje beleženje funkcionalnih zahtev, im- plementacijo rešitve s pomočjo TDD, ki bo ustrezala zapisanim zahtevam, ter sestavo besedila naloge. V prvi fazi se tekom ciklov TDD-ja (poglavje 4.1): a) ustvari množica testov, ki služijo kot specifikacija na- loge, b) tekom preoblikovanj formira končna arhitek- tura naloge. Pomemben poudarek pri razumevanju pomena prve faze je, da se testi tekom razvoja v tej fazi ne pišejo z namenom validacije oz. preverjanja pravilnosti delovanja sistema, ampak samo kot spe- cifikacija zahtev. Ko je razvoj zaključen in končna arhitektura naloge z vsemi funkcionalnostmi imple- mentirana, se te iste teste (lahko) prekvalificira po uporabi in se jih s pridom uporabi še za validacijo pravilnosti delovanja študentskih oddaj (tako kot je to v našem sistemu − peta faza). Še en pomemben poudarek: testi so namenjeni samo razvijalcem ter jih študentje pri reševanju naloge ne pišejo (razen, če je to njihova želja, oz. opazijo potrebo po testih za na- men validacije lastne rešitve). Rešitev je treba implementirati v dveh program- skih jezikih, saj se mora pri opravljanju vaj zaradi dveh različnih študijskih smeri študentom omogočiti možnost izbire programskega jezika (C# ali C++). V praksi to poteka tako, da se najprej s TDD ustvari re- šitev v enem programskem jeziku, nato pa sledi roč- na preslikava kode še za drugi programski jezik. Pri tem skrbimo za ohranitev strukture razredov, metod, testov in notranjih implementacij. Druga faza je namenjena pripravi predloge, ki jo dobijo študentje kot osnovo in vsebuje prototipe me- tod, ki jih morajo implementirati. Predlogi (za vsak programski jezik ena) se vključno z navodili naloge objavita študentom v spletni učilnici. Sledi čas, na- menjen reševanju naloge s strani študentov. Tretja faza je izpeljana po pretečenem roku za oddajo naloge. Sistem iz spletne učilnice samodejno prenese oddane naloge in jih razdeli v ločene mape (vsak študent ima svojo mapo). Četrta faza je namenjena preverjanju podobnosti oddanih nalog pred testiranjem. V ta namen se upo- rabi skripta (Algoritem 4.4), ki za preverjanje upora- bi sistem Moss. Odziv je datoteka HTML, ki vsebuje seznam parov datotek z odstotki ujemanja podobno- sti. Pare datotek s (pre)velikim odstotkom ujemanja pedagoško osebje ročno preveri. Peta faza je namenjena obdelavi in testiranju na- log. Pred začetkom testiranja se v vsako študentsko mapo dodata dve datoteki: prva vsebuje teste, dru- ga pa je namenjena gradnji sistema (angl. Makefi- le). Za vsakega študenta se zažene zabojnik Docker (poglavje 4.3), ki ima dostop samo do študentske mape. Znotraj zabojnika se izvede še zadnji korak predpriprave, kjer se oddana naloga prilagodi z da- toteko za gradnjo sistema (poglavje 4.4). Sledi zače- tek testiranja, ki se izvede po principu črne škatle, in sicer po metodi testiranja enot. Enote so metode, ki jih implementirajo študenti. Za posamezno enoto je zapisanih več testov (poglavje 5), katerih povratne informacije se shranijo v t. i. datoteki odzivov. Testi- ranje se ovrednoti kot uspešno samo v primeru, če je testirana rešitev uspešno prestala vse teste. Sistem ima za izvajanje testov predvideno tudi časovno omejitev, znotraj katere se morajo testi zaključiti. V nasprotnem primeru se testiranje prekine in test se ovrednoti kot neuspešen. Šesta faza je objava rezultatov. Uporabi se ocenje- valna razpredelnica, katere prenos je mogoč iz sple- tne učilnice. Razpredelnica vsebuje podatke za vse študente, ki so bili vključeni v nalogo. Za vsakega študenta z oddano nalogo se izpolnita dva podatka: komentar in ocena. Podatka pridobimo iz datoteke odzivov. S komentarjem se študentu podajo povra- tne informacije testov. Samo ocenjevanje pa poteka binarno – študent lahko pridobi vse točke ali nič točk. Ocena se določi glede na to, ali je študentova rešitev uspešno prestala vse teste ali ne. Dopolnjeno razpre- delnico upravljavci sistema na koncu naložijo v sple- tno učilnico, s čimer se zaključi ocenjevanje naloge. 4.1. Funkcionalne zahteve in priprava testov Naloge pri posameznih snoveh iz programiranja morajo biti sestavljene z namenom osvajanja točno določenih konceptov. Na primer preverjanje znanja Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja U P O R A B N A I N F O R M A T I K A42 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja uporabe podatkovnih struktur (implementiranih v programerskih knjižnicah) zajema tako preverjanje njihovih metod kot tudi širši pomen uporabe le-teh znotraj algoritmov. Ko je znanje, ki ga mora študent osvojiti, dobro opredeljeno, pa se lahko oblikujejo specifikacije naloge ter funkcionalne zahteve, ki jih mora naloga vsebovati. Seznam funkcionalnih zahtev nato uporabimo kot osnovo za pisanje testov s pomočjo TDD. Celoten postopek (Beck, 2003) razvoja program- ske kode po TDD zajema naslednje korake: 1. Zapiše se test, namenjen preverjanju majhnega koščka funkcionalnosti naloge, in se ga požene. 2. Test pade. 3. Zapiše se najmanjša možna koda, ki zadošča te- stu. 4. Izvedejo se vsi do takrat napisani testi (čemur pravimo tudi regresijsko testiranje), ki morajo biti zdaj uspešni. 5. Izvede se preoblikovanje programske kode (angl. Refactoring), ki izboljša njeno notranjo strukturo, vendar ne spremeni obnašanja navzven. Ponovno se izvedejo vsi testi. 6. Če niso izpolnjene vse na začetku zapisane funk- cionalne zahteve, ponovimo vse do zdaj zapisane korake s pisanjem novega testa za neimplementi- rano funkcionalnost. Sicer je razvoj zaključen. Na tem mestu podajmo praktičen primer testa za implementacijo ene izmed funkcionalnosti naloge: Študent mora osvojiti znanje uporabe statične podat- kovne strukture Tabela. Ena izmed njenih osnovnih metod je metoda pripravi(velikost), ki poskrbi za začetno inicia- li-zacijo tabele s podano celoštevilsko vrednostjo velikost, ki jo metoda prejme kot argument. Funkcionalnost na se- znamu zahtev za implementacijo je naslednja: »Metoda pripravi(velikost) mora pri prejetju vrednosti velikosti, ki je manjša ali enaka 0, uvodno nastaviti ter vrniti celo-šte- vilsko polje ničelne velikosti.« Test, ki bo izpolnjeval preverjanje te funkcional- nosti, po izvedbi prvih dveh korakov vsebuje nasle- dnjo kodo: Ker imamo do zdaj napisan samo en test, lahko četrti korak preskočimo (pri dodanih novih testih pa Algoritem 4.1: Test za preverjanje pravilnosti implementacije metode pripravi(velikost). Implementacija metode pripravi(velikost) z izpolnjeno opisano funkcionalno zahtevo po izvedbi tretjega ko- raka TDD cikla vsebuje: se bo ta korak vedno izvedel). Sledi peti korak cikla TDD, kjer izvedemo preoblikovanje napisane kode − Algoritem 4.2: Del kode, s katero bo metoda pripravi(velikost) izpolnjevala funkcionalno zahtevo. U P O R A B N A I N F O R M A T I K A 432020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja spremenljivke pri nespremenjenem delovanju) − ter izvedemo vse teste. Peti korak cikla (preoblikovanje) je v osnovi iz- redno pomemben gradnik TDD-razvoja. Na danem primeru je zaradi preprostosti sicer prišlo samo do odstranitev spremenljivke, vendar bi z nadaljeva- njem šestega koraka (dodajanje novih zahtev) hitro prišlo do kompleksnejših preoblikovanj, ki bi imele pomemben vpliv na strukturo končne naloge (npr. pripravi(velikost) bi postala razredna metoda, spreme- nila bi se vidnost metode, metoda bi se lahko razdeli- la na več delov itd.). Algoritem 4.3: Del kode, s katerim bo metoda pripravi(velikost) izpolnjevala funkcionalno zahtevo. 4.2. Preverjanje plagiatorstva Skripta za preverjanje plagiatorstva kot vhod prejme absolutno pot do mape študentskih oddaj, ločenih po programskih jezikih. Za vsak jezik se ustvari seznam nalog, ki se posreduje na strežnik Moss s pomočjo datoteke moss.pl (del sistema Moss). Odgovor siste- ma Moss je datoteka HTML z rezultati. Algoritem 4.4: Skripta za preverjanje plagiatorstva s sistemom moss. odstranitev nepotrebne spremenljivke polje (zmanj- ša se število vrstic kode, sprostila se je deklaracija 4.3. zabojnik Docker Zabojnik Docker je v sistemu uporabljen z namenom izolacije testov, zmanjševanja zunanjih vplivov na testiranje ter za varovanje računalnika upravljavca sistema pred morebitnimi zlorabami. Za zagon zabojnika je bilo treba ustvariti sliko Dock- er (Algoritem 4.5), kjer je bila kot osnova uporabljena uradna slika okolja Mono (Docker Inc, 2019). Okolje Mono je odprtokodna implementacija .Net ogrod- ja in omogoča razvoj aplikacij, napisanih v jeziku U P O R A B N A I N F O R M A T I K A44 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja C# na operacijskem sistemu Linux. Uradna slika je razširjena z razvojnimi orodji (angl. build-essential). Gradnja slike (dodatne informacije o tem koraku naj- dete na (Docker Inc., 2019)) se izvede enkrat in objavi na središču Docker (Docker Inc., 2019). Algoritem 4.5: Izdelava slike Docker. zabojnik se zažene ločeno za vsakega študenta z ukazom: Zabojnik se zažene ločeno za vsakega študentra z ukazom: kjer se s parametrom name poda ime zabojnika (v našem primeru je to Naziv). Parameter v pritrdi mapo s študentsko oddajo (parameter pot) na pot / app/ znotraj zabojnika. S tem se aplikaciji znotraj zabojnika omogoči dostop do vseh datotek v mapi s študentsko oddajo. Parameter slika vsebuje povezavo do slike Docker na središču Docker. Na koncu je po- dan še skriptni ukaz, ki se izvede ob zagonu zabo- jnika. Ob izvedbi ukaza pride do premika v mapo app in zagona skripte za gradnjo sistema. Zabojnik je po koncu uporabe treba vedno odstraniti, čemur je namenjen ukaz: 4.4. Datoteki za gradnjo sistema Za zagon testov se uporabljata skripti za gradnjo sistema: C# (Algoritem 4.6) in C++ (Algoritem 4.7). Skripti najprej iz študentskih nalog odstranita vse nepotrebne knjižnice. Sledi zamenjava imena glavne- ga podprograma iz main v xmain (podprogram main je namreč že vključen v testih). Po zamenjavah se združita datoteka s testi in študentska naloga. Združena programska koda se prevede v izvajalno datoteko, ki se nato zažene. Odzivi testov se shranijo v datoteko output. Algoritem 4.6: Datoteka za gradnjo sistema za c#. U P O R A B N A I N F O R M A T I K A 452020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja Algoritem 4.7: Datoteka za gradnjo sistema za c++. 4.5. Namizna aplikacija Za lažjo uporabo sistema je bila s programskim ogrodjem Electron (Electron, 2019) razvita prenosljiva namizna aplikacija, ki deluje kot vodič skozi opisan postopek. Aplikacija izvede samodejen prenos nalog, razvrstitev oddaj v ločene mape ter zgoraj opisane skripte. 5 PReDSTAVITeV OgRODJA IN PRImeRA Preverjanje pravilnosti študentskih oddaj poteka na osnovi vnaprej pripravljenih testov enot. Enote so v našem sistemu metode, ki jih študenti v predlogi im- plementirajo v skladu s podanimi navodili. Pri upo- rabi našega testnega ogrodja študentu ni treba doda- ti niti ene vrstice kode, vendar pa ogrodje študentu vseeno omogoča implementacijo lastnih metod in razredov. Osnovno ogrodje za testiranje je skupno vsem na- logam in je implementirano v obeh jezikih: C# (Al- goritem 5.1) in C++ (Algoritem 5.2). Koda je pri obeh jezikih zelo podobna, s čimer se olajšata sestavljanje nalog in pisanje testov. Glavne komponente ogrodja so: razred Scenarij (od sedaj naprej scenarij), metodi za zagon testov in testne metode. V ogrodju je Sce- narij razred, ki vsebuje podatek o nazivu testirane enote, kratek opis scenarija ter referenco na testno metodo, ki se bo izvedla. V metodi za zagon testov (metoda test_vse) se najprej deklarirajo vsi scenariji, ki se dodajo na seznam. Sledijo zaporedni klici meto- de zazeni_test_scenarij. U P O R A B N A I N F O R M A T I K A46 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja Metoda zazeni_test_scenarij (Algoritem 5.3) je del osnovnega ogrodja, njena naloga je izvedba testa s klicem implementirane testne metode. Metoda vrne informacijo o uspešnosti izvedenega testa. Zaradi možnosti napak med izvajanjem (angl. run time er- rors) je klic metode obdan s prestreznim delom kode (angl. try…catch), ki v primeru napake v datoteko odzivov zapiše poročilo o napaki, ime testirane eno- te ter opis scenarija, celoten test pa se tudi označi kot neuspešen. Algoritem 5.3: Funkcija za zagon posameznega testa. U P O R A B N A I N F O R M A T I K A 472020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja Testna metoda (angl. test case) vsebuje imple- mentacijo testa in se drži vzorca AAA. Najprej se pri- pravijo vhodni podatki, sledi izvedba testirane enote in na koncu še preverjanje, ali se rezultati enote uje- majo s pričakovanimi rezultati. Vsaka testna metoda Algoritem 5.4: Primer testne metode. sprejme dva parametra: opis scenarija in naziv te- stirane enote. Ta podatka se v primeru neuspešno iz- vedenega testa skupaj z razlago zapišeta v datoteko odzivov. Metoda vrne informacijo o uspešnosti testa. Primer testne metode je predstavljen v Algoritem 5.4. U P O R A B N A I N F O R M A T I K A48 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja 6 DISKUSIJA Predstavljen sistem se od sorodnih razlikuje pred- vsem v sočasni uporabi dveh programskih jezikov (C# in C++), kar je tudi največja prednost našega sis- tema. Omogoča objektivno ocenjevanje, kar pa je pri ročnem pregledovanju in testiranju nalog pri več kot 100 študentih in več članih pedagoškega osebja zelo težko doseči. Prav tako se skrajšata čas pregledovan- ja in testiranja nalog (Tabela 1) ter čas objave rezulta- tov, ki vsebujejo poenotene odzive o morebitnih na- pakah. Odzivi študentom povedo, v kateri metodi in pri katerem testu je prišlo do morebitne napake, s či- mer lahko pedagoško osebje oziroma študenti hitreje najdejo mesto napake. To jim je v pomoč pri popravl- janju naloge pred ponovno oddajo iste naloge. Slabosti uporabe sistema so: a) podaljšanje ča- sovnega vložka, potrebnega za pripravo naloge, saj mora pedagoško osebje spisati funkcionalne zahte- ve, implementirati rešitev s pomočjo TDD in sesta- viti predlogo, b) testov se ne objavi, tako da morajo študenti testirati lastno kodo, c) binarno ocenjevanje, kjer že en neuspešen test pomeni nič točk pri nalogi in d) sistem je bolj koristen pri predmetih z večjim številom študentov. Pri ročnem pregledovanju in testiranju nalog je treba poudariti, da se naloge razlikujejo po težavno- sti (Tabela 1), s čimer se čas testiranja poveča. Iz tega razloga smo v Slika 1 za ročni pregled in testiranje nalog uporabili povprečen čas. Za ročni pregled in testiranje ene oddane naloge se glede na naše izku- šnje v povprečju porabi približno 10 minut, medtem ko se za samodejni pregled in testiranje ene oddane naloge potrebuje največ 30 sekund. Slika 1 prikazuje razliko v času med ročnim ter samodejnim pregledovanjem in testiranjem nalog glede na število oddanih nalog, kjer se v povprečju odda 650 nalog na semester. Slika 1 prikazuje potre- ben čas za pregledovanje in testiranje oddane naloge za enega pedagoškega delavca. Pri samodejnem pre- gledovanju in testiranju oddane naloge se čas z več pedagoškimi delavci ne bi spremenil, bi se pa poraz- delil pri ročnem. Med študenti smo izvedli tudi krajšo anketo o uporabi našega sistema. Večjih pripomb glede se- stave in razumevanj nalog niso imeli. Podali pa so željo, da bi imeli dostop do testov, s čimer bi lahko naloge osebno testirali, preden jih oddajo v ocenjeva- nje. Kritika sistema je bila izrečena glede poenotenih odzivov o nepravilno delujoči nalogi, saj se študentje niso znali orientirati, kako odpraviti napako (mne- nje/utemeljitev avtorjev članka: študentom je v odzi- vu podana informacija o metodi in krajši opis testa, pri katerem je prišlo do napake, ne pa točna lokacija napake v programski kodi). Slika 1: Primerjava časov ročnega in samodejnega pregledovanja in testiranja oddanih nalog Vrstilec Stopnja težavnosti čas ročnega pregledovanja in testiranja [min] Naloga 1 4 5 Naloga 2 3 5 Naloga 3 7 10 Naloga 4 8 10 Pregledna naloga 10 20 Povprečje 6,4 10 Tabela 1: Prikaz težavnosti in časa ročnega pregledovanja in testiranja ene oddaje naloge U P O R A B N A I N F O R M A T I K A 492020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja 7 SKleP Za razvoj lastnega ogrodja za testiranje enot smo se odločili, ker smo želeli imeti sistem, ki bo notranje podpiral dva programska jezika (C# in C++), nav- zven pa ponudil identične funkcionalnosti ter upo- rabniško izkušnjo. S tem se je dosegla lažja integra- cija implementiranega sistema v študijski proces, po- hitrilo pa se je tudi pregledovanje in testiranje nalog. Ena izmed primarnih zahtev, ki smo si jo zadali pri implementaciji sistema, je bila tudi ta, da študentom ne dvignemo kognitivne obremenitve pri osvajanju novega znanja še s prilagajanjem na naše ogrodje. To nam je uspelo, saj študentje ni treba prilagajati svoje- ga stila programiranja predlogi, če tega ne želijo. Jim pa je vseeno prepuščena svoboda v primeru, če želijo dodati novi razredi, strukture, metode itd. V prihodnosti želimo v sistem dodati tudi funk- cionalnosti, ki bi študentom omogočile samostojno rabo celotnega sistema, vendar v okrnjeni obliki (brez vseh testov), kot tudi dodati možnosti za predtestira- nja lastnih rešitev za bolj splošne napake (neveljavna sprememba strukture predloge; metoda vsebuje ne- dovoljene klice iz programskih knjižnic, kot je npr. Array.Sort(); …). LITeRATURA [1] Aiken, A. (15. 12 2018). A System for Detecting Software Similarity. Pridobljeno 9. 9 2019 iz https://theory.stanford. edu/~aiken/moss/ [2] Auffarth, B., López-Sánchez, M., Campos i Miralles, J., & Puig, A. (2008). System for automated assistance in correc- tion of programming exercises (sac). Proceedings of CIDUI 2008, (str. 104-113). Lleida. [3] Beck, K. (2003). Test-driven development: by example. Addi- son-Wesley Professional. [4] Bowyer, K. W., & Hall, L. O. (1999). Experience using „MOSS“ to detect cheating on programming assignments. FIE‘99 Frontiers in Education. 29th Annual Frontiers in Education Conference. Designing the Future of Science and Engine- ering Education. Conference Proceedings (IEEE Cat. No. 99CH37011) (str. 13B3-18). IEEE. [5] Coursera Inc. (1. 09 2019). Coursera. Pridobljeno iz https:// www.coursera.org/ [6] Docker Inc. (25. 8 2019). Mono Docker slika. Pridobljeno 25. 8 2019 iz Spletna mesto uradne Mono slike: https://hub.doc- ker.com/_/mono/ [7] Docker Inc. (02. 09 2019). Docker izgradnja slike. Pridobljeno iz https://docs.docker.com/engine/reference/commandline/ image_build/ [8] Docker Inc. (20. 8 2019). Docker središče. Pridobljeno 20. 08 2019 iz https://hub.docker.com/ [9] Docker Inc. (10. 9 2019). Enterprise Container Platform | Doc- ker. Pridobljeno 25. 8 2019 iz https://www.docker.com/ [10] Douce, C., Livingstone, D., & Orwell, J. (2005). Automatic test-based assessment of programming: A review. Journal on Educational Resources in Computing (JERIC), 3. [11] Edwards, S. H. (2003). Using test-driven development in the classroom: Providing students with automatic, concrete feed- back on performance. Proceedings of the international con- ference on education and information systems: technologies and applications EISTA. 3. Citeseer. [12] edX Inc. (1. 9 2019). edX | Free Online Courses by Harvard, MIT, & more. Pridobljeno 1. 9 2019 iz https://www.edx.org/ [13] E-izobraževanje - Wikipedija, prosta enciklopedija. (28. 8 2019). Pridobljeno 1. 9 2019 iz https://sl.wikipedia.org/wiki/E- izobra%C5%BEevanje [14] Electron. (1. 9 2019). ElectronJS. Pridobljeno iz https://elec- tronjs.org/ [15] Gradišnik, M., & Majer, Č. (2016). Mikrostoritve in zabojniki Docker. V M. Heričko, & K. Kous (Ured.), OTS 2016 Sodobne tehnologije in storitve, (str. 10-20). Maribor. [16] Ihantola, P., Ahoniemi, T., Karavirta, V., & Seppälä, O. (2010). Review of recent systems for automatic assessment of pro- gramming assignments. Proceedings of the 10th Koli Calling International Conference on Computing Education Research (str. 86-93). Koli: ACM. [17] LinkedIn Learning. (1. 9 2019). Pridobljeno 1. 09 2019 iz https://www.linkedin.com/learning/topics/business [18] Massive open online course - Wikipedia. (1. 9 2019). Prido- bljeno 1. 09 2019 iz https://en.wikipedia.org/wiki/Massive_ open_online_course [19] Myers, G. J., Sandler, C., & Badgett, T. (2011). The art of soft- ware testing. John Wiley & Sons. [20] Nichols, M. (2007). No. 1: E-Learning in context. E-Primer Se- ries, 27. [21] Romli, R., Sulaiman, S., & Zamli, K. (2010). Automatic pro- gramming assessment and test data generation a review on its approaches. 2010 International Symposium on Information Technology (str. 1186-1192). IEEE. [22] Udacity, Inc. (1. 9 2019). Learn the Latest Tech Skills; Advan- ce Your Career | Udacity. Pridobljeno 1. 09 2019 iz https:// www.udacity.com/ [23] Udemy, Inc. (1. 9 2019). Online Courses - Learn Anything, On Your Schedule | Udemy. Pridobljeno 1. 9 2019 iz https:// www.udemy.com/ [24] Zeller, A. (2000). Making students read and review code. ACM SIGCSE Bulletin (str. 89-92). ACM. [25] Zemljak, A., Novak, D., Čep, A., & Verber, D. (2016). Preverja- nje pravilnosti študentskih nalog programiranja s testiranjem enot. V M. Orel (Ured.), Sodobni pristopi poučevanja prihaja- jočih generacij (str. 556-564). Ljubljana: Polhov Gradec : Edu- vision. Pridobljeno iz http://www.eduvision.si/Content/Docs/ Zbornik%20prispevkov%20EDUvision_2016_SLO.pdf U P O R A B N A I N F O R M A T I K A50 2020 - πtevilka 1 - letnik XXVIII Aleš Čep, Damijan Novak, Jani Dugonik: Samodejno preverjanje pravilnosti študentskih nalog IZ programiranja  Aleš čep je asistent in doktorski študent na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Njegova raziskovalna področja vključujejo umetno inteligenco v igrah ter evolucijsko računanje.  Damijan Novak je leta 2011 diplomiral na Fakulteti za elektrotehniko, računalništvo in informatiko Univerze v Mariboru. Trenutno je asistent in doktorski študent z večjim številom znanstvenih člankov in prispevkov. Njegova raziskovalna področja obsegajo računsko kompleksnost v igralnih svetovih, umetno inteligenco v igrah ter vzpodbujevalno učenje (veja strojnega učenja). Na mednarodni znanstveni konferenci CGAT 2017 mu je bilo za članek “An aspect-based classification of real-time strategy game worlds” podeljeno tudi priznanje za najboljši študentski znanstveni prispevek.  Jani Dugonik je leta 2010 diplomiral in leta 2013 magistriral na Fakulteti za elektrotehniko, računalništvo in informatiko, ki je članica Univerze v Mariboru. Trenutno je doktorski študent in asistent na fakulteti za elektrotehniko, računalništvo in informatiko. Njegova raziskovalna področja vključujejo evolucijsko računanje, optimizacijo, procesiranje naravnega jezika in globoko učenje.