AUTOLABEtt automatiskt laborationsrättningssystem

An automated laboratory work correction system

Mikael Norström

Fakulteten för matematik och datavetenskap

Dataingenjör

15 hp

Handledare: Lothar Fritsch

Examinator: Karl-Johan Grinnemo

2017-10-19

Sammanfattning

Användningen av automatiserade system är en vanlig lösning för att underlätta en manuell

arbetsbörda inom många områden. Autolab är en prototyp av ett automatiskt

laborationsrättningssystem avsett att kunna användas som ett hjälpmedel inom undervisning för att

reducera arbetsbördan för lärare. Examensarbetet har inneburit att skapa och integrera ny

funktionalitet till systemet. Bland annat att skapa en enklare plagiatkontroll baserad på

strängmatchning för att upptäcka och förhoppningsvis förbygga fusk mellan studenters inlämnade

laborationer. För att underlätta förståelsen till användare för hur Autolab fungerar skapades

dokumentation över hur systemet används som både lärare och student. Efter att analyserat vad

som implementerats till Autolab ges förslag på vad som kan förbättras i systemet till framtiden.

Abstract

The use of automated systems is a common solution to facilitate manual labor in many areas. Autolab

is a prototype of an automated correction system for laboratory work with the purpose of being used

as a tool in teaching. The thesis work involved creating and integrating new functionality to the

system. Among other things, a simple plagiarism control based on string matching to detect and

hopefully prevent cheating between students submitted laboratory work have been created. In order to

facilitate understanding of how Autolab function a documentation about how the system is used as

both teacher and student have been created. After analyzing the implementation in Autolab

suggestions are presented on what can be improved in the system for the future.

FigurlistaKapitel Namn Sida2.01 Mönster inom en text 52.02 Hashat mönster inom en text 52.03 Pseudokod för algoritmen Rabin-Karp 63.01 Användargränssnitt överblick i Autolab för lärare och studenter 73.02 Startsida 83.03 Lista Kurs 93.04 Lägg till Kurs 103.05 Visa Kurs 113.06 Uppdatera Kurs 123.07 Lista labb 133.08 Lägg till labb 143.09 Visa labb 153.10 Uppdatera labb 163.11 Lista användare 173.12 Visa användare 183.13 Uppdatera användare 193.14 Startsida för en student 203.15 Labbkvitto 203.16 Lista kurs 213.17 Gå med i kurs 223.18 Gå med i kurs meddelande 223.19 En students gränssnitt för att lämna in en laboration 233.20 Inlämnad labb väntar på rättning 243.21 Inlämnad labb resultat/meddelande 243.22 Överskådlig bild av Autolab 253.23 Förenklad webbapplikationsserver flödesfigur 253.24 Överblick av samlingarna inom Autolab databasen 263.25 Inlämningsflöde till inlämningsservern 283.26 Användningsfall inom Autolab 293.27 Visa ett objekt 303.28 Lägg till ett objekt 303.29 Uppdatera ett objekt 313.30 Arkivera ett objekt 313.31 Gå med i en kurs 323.32 Lämna in en laboration 323.33 Listning av objekt 333.34 Plagiatkontroll flöde för en inlämning 343.35 Plagiatkontroll flöde för en inlämning 353.36 Normalisering för plagiatkontrollen 353.37 Exempel på en inlämning som genomgått normalisering 363.38 Algoritm för plagiatkontrollen 373.39 Implementationen av RollingWord och RollingPattern 373.40 Evaluering för plagiatkontrollen 394.01 En inlämning 414.02 En plagierad inlämning 41

Innehållsförteckning1 Introduktion.............................................................................................................................................12 Bakgrund.................................................................................................................................................4

2.1 Relaterat arbete................................................................................................................................42.2 Teori bakom plagieringskontrollen..................................................................................................5

3 Design och implementation....................................................................................................................73.1 Övergripande design........................................................................................................................73.2 Detaljerad design...........................................................................................................................25

4 Evaluering och utvärdering...................................................................................................................395 Slutsats..................................................................................................................................................43

1 Introduktion

Vid varje universitet kan det finnas kurser som innehåller laborationsmoment som innebär att

studenter ska lämna in en lösning i form av ett program. En sådan kurs består av ett flertal

studenter för varje lärare eller laborationshandledare, där läraren eller laborationshandledaren

ansvarar för att granska var students laboration samt de absoluta resultaten som laborationen

genererar. Processen att granska varje students laboration tar upp en signifikant del av en lärares

eller laborationshandledares tid, tid som studenten befinner sig i ovisshet om studenten har blivit

godkänd eller erhåller en retur som i sin tur måste lämnas in på nytt och granskas av en lärare eller

laborationshandledare. För att åtgärda den tidförlust som ansågs existera påbörjades en prototyp av

ett system som kunde ta över granskningsprocessen av laborationer, prototypen gavs namnet

Autolab. Autolab bygger på att studenter själva lämnar in sin kodlösning till Autolab som efter

granskning objektivt besvarar ifall kodlösningen är godkänd eller ej. Utöver tidsaspekten att

granska laborationer finns även ytterligare ett tidskonsumerande moment som ingår i

laborationskontrollen, kontroll av plagiat. Plagiering är förekommande vid universitet [1] och

orsakerna kan variera från att elever inte har tillräckligt med förkunskap, känner tidspress eller

kanske vill ta den lätta vägen till ett betyg i kursen. Oavsett vad orsaken är ses plagiering som ett

allvarligt brott mot universitets regler och är något kursansvariga lärare är skyldiga att försöka

upptäcka. Tidsaspekten att kontrollera plagiering är dock något som kan orsaka att lärare drar sig

från att vara så noggranna som kan krävas för att upptäcka plagiat. För att underlätta för lärare bör

Autolab utnyttja plagiatdetektering. Detekteringen bör eftersträva att vara enkel tillhands för lärare

att utnyttja och ska upptäcka olika typer av misstänkt plagiering och flagga dessa automatiskt vid

inlämning för att reducera en lärares arbetsbörda då lärare bara behöver granska de flaggade

laborationerna.

Prototypen av Autolab består av fyra typer: användare, kurser, laborationer och inlämningar.

Systemet lagrar information om typerna i en databas. Användare är bestående av lärare och

studenter vilka kan logga in till systemets server, servern presenterar ett användargränssnitt.

Möjligheten inom användargränssnittet för lärare består av att skapa kurser och inom kurserna

skapa laborationer. En lärare kan granska både kurser och laborationer individuellt och i listor.

Studenter som loggar in har möjligheten att gå med i kurser samt göra inlämningar av laborationer

genom att klistra in sin kod i programspråket C i en textruta som vidarebefordrar koden till en

1

inlämningsserver vilken rättar laborationerna. Laborationer som kan lämnas in visas i listor. Vidare

har studenter tillgång till ett kvitto för varje kurs, där kvittot listar varje godkänd laboration.

Målet med projektet innebär att bidra till systemets funktionalitet innefattande att lägga till

möjlighet för lärare att visa systemets användare i en lista. För listor i systemet önskas det att

sökmöjlighet, filter och paginering implementeras. Lärare ska kunna visa enskilda användare och

kunna revidera en användares information. Existerande information så som kurser och laborationer

ska kunna arkiveras från systemet utan att påverka användare vilka varit delaktiga i en arkiverad

kurs samt eller utfört en arkiverad laboration. Laborationer ska kunna skapas separat utan att

tillhöra en kurs. Laborationer ska kunna listas. Från en kurs ska en lärare kunna nå listan och välja

en laboration. En student som gör en inlämning av en laboration ska kunna lämna in ett helt projekt

av laborationen i form av en zipfil. Autolab ska kunna packa upp zipfilen känna igen vilka filtyper

som packats upp och skapa en fungerande makefil vilken ska kunna identifieras av

inlämningsservern. Till Autolab ska en enkel plagiatkontroll implementeras vilken ska omvandla

inlämningar till strängar och jämföra om några strängar är identiska och därmed flagga misstänkt

plagiat. En sida ska skapas inom användargränssnittet vilken tillåter lärare att granska misstänkta

plagiat. Om tid finns ska undersökning utföras om plagiatkontrollen kan förbättras, innebärande att

undersöka andra algoritmer som används vid plagiatkontroll och implementera en av dem,

funktionaliteten av implementationen ska undersökas. Slutligen är målet att ge möjlighet för

Autolab att hantera fler programspråk än C. Den fullständiga projektspecifikationen bifogas som

appendix.

Det arbetet som utförts innefattade att skapa funktioner för användare, laborationer och kurser

inom systemet som nämnt ovan. Mycket av arbetet bestod av att skapa funktioner vilka band

samman användargränssnittet med databasen via en vy för varje typ. Funktionerna ansvarade för

att kunna visa, arkivera, uppdatera, visa objekt i en lista med sökmöjligheter samt filtervärden,

zipfil inlämning och utföra plagiatkontroll av laborationer. Arbetet innebar att sätta sig in i de

tekniker som redan systemet utnyttjade sig av. Det innebar att lära sig programspråket Python [2]

med ramverket Flask [3], databasen MongoDB [4], nyttja Html [5] och Jinja [6]. Det mesta från

målbeskrivningen lyckades utföras. Delar som utelämnades från målbeskrivningen på grund av

tidsbrist innefattade att utöka antalet programspråk. Delar som är delvis fullbordades men behöver

förbättras innefattar den mer avancerade plagiatkontrollen.

2

Den resterande delen av uppsatsen har följande disposition: Ett kapitel om bakgrund, där först

relaterat arbete presenteras och vidare ges en kort teoribakgrund för att ge förståelse för algoritmen

som användes. Kapitel tre ger en översikt av systemet från ett användarperspektiv vilket tillåter

läsaren att lättare förstå systemet, vidare i kapitlet presenteras och beskrivs funktionaliteten av

systemets användningsfall. Kapitel 4 berör den implementation som utförts samt resultat och

tankar kring implementationen. Rapporten avslutas med en sammanfattning av arbetet i kapitel 5.

3

2 Bakgrund

Kapitlet inleds med att presentera arbete vilket är relaterat till Autolab, där insikt ges om

automatiska laborationsrättningssystem och systemet Kattis. Vidare i kapitlet ges den

teoribakgrund som behövs för att förstå arbetet med plagiatkontrollen.

2.1 Relaterat arbete

Ett automatiskt laborationsrättningssystem kan generellt beskrivas som ett automatiskt

utvärderingssystem vilket har uppgiften att erhålla en uppgift och efter ett antal parametrar

utvärdera resultatet av uppgiften. Uppgiften som erhålls är vanligtvis laborationer eller övningar

inom datavetenskapliga kurser, då de uppgifterna har svar vilka kan utvärderas av ett program

baserat på en lista av inmatning som ska resultera i en lista av utmatning för att anses vara korrekt.

Kring systemet byggs någon typ av användargränssnitt upp för att tillåta lärare och studenter att

interagera med systemet och kunna erhålla återkoppling. Att använda sig av ett automatiskt system

för rättning har visat sig vara fördelaktigt inom undervisning för både lärare och studenter [7].

Student feedback vid automatiska rättningssystem visar att studenterna upplever bättre

återkoppling och möjlighet till iterativ inlärning [8]. Det existerar ett flertal automatiska

utvärderingssystem och för de som används inom undervisning har utformningen en liknande

funktionalitet [9]. Det automatiska utvärderingssystemet som Autolab tagit mycket inspiration från

vid utveckling är systemet Kattis [10]. Kattis är ett större system än enbart automatiskt

laborationsrättning. För den automatiska laborationsrättning bygger systemet på fyra pelare: kurser,

laborationer, användare och inlämningar vilka täcker samtliga användningsfall vid användning i

undervisning. Kurser innehåller laborationer, användare är delaktiga i kurser och kan utföra

inlämningar för laborationer där laborationerna utvärderas av systemet och erbjuder ett resultat till

användaren. Kattis används för att låta studenter utföra en eller flera inlämningar och bli

utvärderade samt godkända av Kattis innan de gör inlämningen inom kursen direkt till läraren,

vilket resulterar i en reducerad arbetsbörda för läraren. Kattis visar på att systemet leder till att mer

högkvalitativ och korrekt kod utförs av studenter, då systemet kan fånga samtliga special och

gränsfall vilka en lärare inte alltid har tiden till att testa vilket tillåter studenter att bli godkända

trots att den kod som lämnas in inte är helt korrekt.

4

Figur 2.01: Mönster i en sträng.

Figur 2.02: Hashat mönster i en sträng.

2.2 Teori bakom plagieringskontrollen

Strängmatchningsalgoritmer har uppgiften att upptäcka om mönster kan återfinnas inom en helhet,

proceduren är känd som linjär mönstermatchning [11]. För texter används en strängmatchnings-

algoritm för att undersöka om ett mönster i form av ett ord kan återfinnas inom en annan text.

Ett enkelt exempel ges i figur 2.01 där en fil innehållande en text genom en funktion ställer frågan

till en algoritm om ett mönster existerar inom filens text. Genom att känna till längden på mönstret

kan algoritmen gå igenom texten bokstav för bokstav inom ett fönster som matchar mönstrets

storlek. För varje ny bokstav som uppdateras i fönstret så jämförs fönstret mot mönstret för att se

om strängarna inom mönstret och fönstret matchar. Att jämföra två strängar med varandra är mer

tidskrävande än att jämföra två nummer. Därför utför vissa algoritmer en hashning av texten samt

mönster innan sökning efter mönstret inom texten påbörjas. Hashningen tillåter en snabbare

genomgång av texten för att finna ett mönster, men hashningen kan orsaka att falska matchningar

återfinns i de fall två olika strängar hashas till samma värde, detta löses genom att jämföra två

strängar i klartext motsvarande den hashvärdes matchning som upptäckts. För att motsvara ett

fönster som glider genom texten bokstav för boktstav används tekniken rullande hash (eng ’rolling

hash’) [12]. Tekniken uppdaterar hashvärdet som motsvarar fönstret genom att utföra en operation

genom att addera hashvärdet för den nya bokstaven som anländer till fönstret samt subtrahera

hashvärdet för den bokstav som lämnar fönstret, ett exempel visas i figur 2.02.

5

Figur 2.03: Rabin-Karp psuedokod.

Vid valet av en algoritm som kunde finna mönster inom en sträng var det slutgiltiga valet Rabin-

Karp [13] en av flera algoritmer som kunde implementeras för plagiatkontroll. Jämfört mot några

andra populära strängmatchningsalgoritmer som Knuth-Morris-Pratt [14] och Booyer-Moore [15]

så tillåter Rabin-Karp en matchning av flera mönster. Algoritmer likt CodeMatch [16] vilka är

väldigt noggranna men tar förhållandevis lång tid att exekvera ansågs inte passa sig för syftet att

lokalt kontrollera en students laborationer mot dennes klasskamraters laborationer. En algoritm

som vi övervägde att använda var Winnowing [17] vilket inte är en direkt

strängmatchningsalgoritm utan en tokenbaserad [18] algoritm, Rabin-Karp tillät dock en enklare

implementation vilket krävdes på grund av tidsaspekten, inspiration från Winnowing användes i

normalisering till Rabin-Karp implementationen i avsnitt 3.2.

Figur 2.03 beskriver psuedokoden för Rabin-Karp, s representerar den text som ska genomsökas,

där n är textens längd. subs representerar den samling av mönster som skall jämföras mot texten. m

representerar längden på varje enskilt mönster i samlingen subs. Varje mönster i samlingen subs

omvandlas till ett hashvärde och sparas till en hashsamling av mönster. Ur den ursprungliga texten

skärs ett fönster ut lika stort som längden på ett mönster, fönstervärdet hashas. Iteratorn beskriver

genomgången av den ursprungliga texten, där fönstret skiftar tecken för tecken i form av rolling

hash till dess att varje version av fönstret har hashats samt kontrollerats om hashvärdet existerar

inom samlingen av mönster samt om även den riktiga texten i fönstret finns inom samlingen av

mönster subs i klartext. I detta fall returneras en position vid matchning, men vad som händer vid

en matchning kan modifieras på många sätt och i detta fall för att passa sig till en typ av

plagiatkontroll som beskrivs i avsnitt 3.2.

6

Figur 3.01: Användargränssnitt överblick i Autolab för lärare och studenter.

3 Design och implementation

Kapitlet inleds med en övergripande design samt åtföljs av en mer detaljerad design. Inom den

övergripande designen ges en överblick av användargränssnittet för att ge en initial förståelse för

hur systemet fungerar ur ett användarperspektiv. Inom den detaljerade designen följer en förklaring

av hur systemet är uppbyggt och hur dess beståndsdelar interagerar.

3.1 Övergripande design

Autolab är i nuvarande form utformat för att utnyttjas av två typer av användare, lärare och

studenter. Lärare och studenterna interagerar med Autolab via ett användargränssnitt där typ av

användare avgör åtkomst samt presentation inom Autolabs användargränssnitt i form av webbsidor

vilket beskrivs översiktligt i figur 3.01. Inom detta kapitel kommer vi att granska Autolabs

användargränssnitt ur ett lärar- och studentperspektiv för att skapa en grundförståelse för hur

Autolab är uppbyggt och används. Kapitlet inleder med att beskriva Autolab ur ett lärarperspektiv.

7

Figur 3.02: Startsida.

När du loggar in som en lärare kommer du till en startsida. Startsidan visar ett navigeringsfält med

alternativen: startsida, kurslista, labblista, användarlista och logga ut. Startsidan har en

instrumentbräda innehållande aktiv information till vänster samt en lista med kurser till höger.

Listan med kurser visar: kursnamn, kurskod, antal studenter aktiva inom kursen. En kurs kan nås

genom att klicka på kursnamnet som agerar som en länk till kursen. Genom att klicka på länken

”Alla kurser” ges en översikt för samtliga kurser.

8

Figur 3.03: Lista kurs.

En användare som klickat på navigeringsfält valet ”Course List” kommer till sidan ”Lista kurs”.

Här kan användaren genom att klicka på länken ”Add new course” komma till sidan ”Lägg till

kurs”. Den lista med kurser som sidan visar beror på vad användaren valt för sökord och

filtervärde. När en lärare först når sidan visas samtliga kurser i listan. Genom att användaren

skriver in ett sökord i textboxen och väljer ett filtervärde kan användaren välja vad listan visar. De

filtervärden som kan väljas är: kurskod, termin och kursnamn. I de fall listan är lång delas den upp

i sidor och två knappar visas, en för framåt och en för bakåt, vilket tillåter att användaren bläddrar

igenom listan. Genom att klicka på en kurskod i listan kan användaren visa den specifika kursen.

9

Figur 3.04: Lägg till kurs.

En lärare som valt att lägga till en ny kurs befinner sig på sidan ”Lägg till kurs” (se figur 3.04). En

lärare kan här bestämma attributen: namn, kod, lösenord, termin samt beskrivning för kursen. Att

fylla i ett lösenord är frivilligt, lösenordet förhindrar att fel studenter kommer med i kursen. När

användaren fyllt i all nödvändig information och vill bekräfta att den nya kursen ska läggas till, ska

läraren klicka på knappen ”Save Changes”. Då läraren av någon anledning inte vill lägga till

kursen ska läraren klicka på knappen ”Cancel & Return”.

10

Figur 3.05: Visa kurs.

När en användare anländer till sidan ”Visa kurs” visar sidan kursens namn som huvudrubrik följt

av kursens kurskod, termin samt kursbeskrivning. Sidan visar till höger en lista med laborationer

som tillhör kursen. En användare kan visa enskilda laborationer genom att klicka på

laborationsnamnet. En användare kan uppdatera en laboration i listan genom att klicka på länken

”edit” som följer laborationsnamnet. En användare kan lägga till en laboration till kursen genom

att klicka på länken ”Add Lab”. En lista nederst på sidan ger läraren en översikt över samtliga

studenter som är delaktiga i kursen. I listan med studenter kan en lärare se när studenten senast var

aktiv och hur studenten lyckats med kursens laborationer. Genom att klicka på utropstecknet kan

en lärare se om studenten är misstänkt för att ha plagierat laborationen. Genom att klicka på länken

”Edit Course” längst ned på sidan kan en lärare uppdatera kursen. Genom att klicka på länken

”Archive Course” kan en lärare arkivera kursen, en arkiverad kurs visas inte längre i de normala

fallen inom sökning av kurser. En kurs som arkiverats uppdateras med en indikator, ”archived”, till

skillnad från indikatorn, ”active”, som kan ses under kursnamnsrubriken i figur 3.05.

11

En lärare som valt att uppdatera en kurs befinner sig i sidan ”Uppdatera kurs” enligt figur 3.06. En

lärare kan här bestämma attributen: namn, kod, lösenord, termin samt beskrivning för kursen. När

användaren fyllt i önskade uppdateringar och vill bekräfta ändringarna ska läraren klicka på

knappen ”Save Changes”. Då läraren av någon anledning inte vill utföra ändringarna ska läraren

klicka på knappen ”Cancel & Return”.

12

Figur 3.06: Uppdatera kurs.

En användare som klickat på navigeringsfält valet ”Lab List” kommer till sidan ”Lista labb”. Här

kan användaren genom att klicka på länken ”Add New Lab” för att komma till sidan ”Lägg till

labb”. Den lista med laborationer som sidan visar beror på vad användaren valt för sökord och

filtervärde. När en lärare först anländer till sidan visas samtliga laborationer i listan. Genom att

användaren fyller i ett sökord inom textboxen och väljer ett filtervärde kan användaren välja vad

listan visar. De filtervärden som kan väljas är efter en laborations attribut: namn och programspråk.

I de fall listan är lång delas den upp i sidor och två knappar visas, en för framåt och en för bakåt

vilket tillåter att användaren bläddrar igenom listan. I listan med kurser som visas kan en

användare klicka på laborationsnamnet då de agerar som en länk till att visa den specifika

laborationen.

13

Figur 3.07: Lista labb.

En lärare som valt att lägga till en ny laboration befinner sig på sidan ”Lägg till labb”(se figur

3.08). En lärare kan här bestämma attributen: titel, tidsåtgång, svårighetsnivå samt en

beskrivningstext vilken ska förklarar laborationen. Genom att klicka på ”Add input/Output Test”

kan läraren bestämma de tester vilka bestämmer ifall en laboration klassas som godkänd eller ej.

Läraren kan då välja att fylla i den utmatning som förväntas från laborationen. Läraren kan också

välja att fylla i informationen av inmatning som ska krävas för en specifik utmatning. När läraren

fyllt i informationen och vill bekräfta att den nya laborationen ska läggas till ska läraren klicka på

knappen ”Save Changes”. Då läraren av någon anledning inte vill lägga till laborationen ska

läraren klicka på knappen ”Cancel & Return”.

14

Figur 3.08: Lägg till labb.

När en användare anländer till sidan ”Visa labb” visar sidan kursen som laborationen tillhör som

huvudrubrik följt av laborationens namn som underrubrik och laborationens beskrivning. En

användare kan i sidan se en lista av den utmatning som förväntas av laborationen, som resultatet av

en given inmatning. En användare kan välja att söka efter sin laboration på en lokal enhet genom

att klicka på knappen ”Browse”. Filtyperna som stöds är av typen zip. När användaren valt en fil

visas filnamnet. När en användare vill bekräfta att det är den korrekta zipfilen klickar användaren

på ”Upload”. En användare kan istället för att ladda upp en zipfil välja att klistra in koden i en

textbox. När användaren klistrat in koden och vill bekräfta en uppladdning ska användaren klicka

på knappen ”Submit Code”. I de fall då användaren inte vill lämna in en laboration kan användaren

klicka på knappen ”Cancel & Return”. När knappen ”Upload” eller ”Submit Code” klickats visas

resultat av den inlämnade laborationen, resultatet beskrivs senare i rapporten i figur 3.21. En lärare

kan klicka på knappen ”Archive Lab” för att arkivera en laboration. Arkiveringen innebär att inga

nya elever har möjlighet att utföra den specifika laborationen, medan elever som redan har klarat

laborationen har kvar resultatet. En lärare kan uppdatera en laboration genom att klicka på länken

”Edit Lab”.

15

Figur 3.09: Visa labb.

Figur 3.10: Uppdatera labb.

En lärare som väljer att uppdatera en laboration går till sidan ”Uppdatera labb” (se figur 3.10). En

lärare kan här uppdatera attributen: titel, tidsåtgång, svårighetsnivå samt en text vilken ger en

beskrivning av laborationen. Genom att klicka på ”Add input/Output Test” kan läraren uppdatera

de tester vilka bestämmer ifall en laboration klassas som godkänd eller ej. När läraren fyllt i

informationen och vill bekräfta en uppdatering ska läraren klicka på knappen ”Save Changes”. Då

läraren inte vill uppdatera laborationen ska läraren klicka på knappen ”Cancel & Return”.

16

Lärare som klickat på navigeringsfält valet ”User List” kommer till sidan ”Lista användare”. Den

lista med användare som sidan visar beror på vad en lärare valt för sökord och filtervärde. När en

lärare först anländer till sidan visas samtliga användare i listan. En lärare kan välja vad listan visar

genom att att fylla i ett sökord inom textboxen och välja ett filtervärde i rullistan. De filtervärden

som kan väljas är efter en användares attribut: användarnamn, födelsenamn och e-mejladress. I de

fall listan är lång delas den upp i sidor och det framkommer två knappar, en för framåt och en för

bakåt vilket tillåter att användaren bläddrar genom listan. Inom listan med användare som visas

kan en lärare klicka på ett användarnamn då de agerar som länkar till sidan för specifika

användare.

17

Figur 3.11: Lista användare.

Figur 3.12: Visa användare.

Då en lärare begärt att visa information om en given användare så visas sidan ”Visa användare”

enligt figur 3.12. Sidan visar som rubrik användarkategori d.v.s. lärare eller student. En

informationsbox visar användarens attribut: användarnamn, födelsenamn, e-mejladress samt senast

aktivitet. Sidan visar en lista av listor, där en lista inom listan utgörs av en kurs med tillhörande

laborationer en student är aktiv inom. Inom listan visas laborationernas namn samt om studenten

har blivit godkänd för motsvarande laboration. En lärare som vill uppdatera information för en

användare kan klicka på länken ”Edit User”.

18

En lärare som väljer att uppdatera en användare befinner sig i sidan enligt figur 3.13. En lärare kan

här uppdatera attributen: användarnamn, födelsenamn, e-mejladress samt användarnivå.

Användarnivån är ett binärt attribut och avgör om användaren klassas som en student eller som en

lärare. Attributet existerar i de fall en student blir en lärare eller vice versa. När läraren fyllt i

informationen och vill bekräfta en uppdatering ska läraren klicka på knappen ”Save Changes”. Då

läraren inte vill uppdatera användaren ska läraren klicka på knappen ”Cancel & Return”.

19

Figur 3.13: Uppdatera användare.

Figur 3.15: Labbkvitto.

Kapitlet har hittills beskrivit användargränssnittet för lärare inom Autolab. När en student loggar in

till Autolab visas en startsida (se figur 3.14). Sidan visar studentens laborationer i en lista. Listan

med laborationer innehåller laborationens namn, vilken kurs laborationen tillhör, status för en

laboration, slutligen visas antal inlämningsförsök. Statusalternativen för en laboration anger om

laborationen är inlämnad eller inte, samt om laborationen är inlämnad visas om laborationen är

godkänd eller inte. En student kan genom att klicka på ”View” inom attributet ”status” visa den

laboration som blev godkänd. En student kan genom att klicka på länken ”(View All)” inom

attributet ”Submission Count” visa samtliga inlämnade laborationsförsök som studenten utfört.

Längst ned på sidan visas en lista av kurser med respektive kurskvittolänk. En student kan genom

att klicka på kurskvittolänken visa samtliga laborationer inom den kursen och se vilka laborationer

som har slutförts samt vilka som återstår (se figur 3.15).

20

Figur 3.14: Startsida för en student.

Figur 3.16: Lista kurs.

En student som klickat på navigeringsfält valet ”Course List” kommer till sidan ”Lista kurs”. Den

lista med kurser som sidan visar beror på vad studenten valt för sökord och filtervärde. När en

student först når sidan visas samtliga kurser i listan, genom att användaren skriver in ett sökord i

textboxen och väljer ett filtervärde kan användaren välja vad listan visar. De filtervärden som kan

väljas är: kurskod, termin och kursnamn. I de fall listan är lång delas listan upp i sidor och två

knappar visas, en för framåt och en för bakåt, vilket tillåter att användaren bläddrar igenom listan.

En student kan välja att gå med i en kurs genom att klicka på länken ”Join Course”. En student

som klickat på ”Join Course” kommer till sidan ”Gå med i kurs” enligt figur 3.17. En student

behöver bekräfta att den verkligen vill gå med i kursen genom att klicka på knappen ”Join Course”

och i de fall kursen är lösenordsskyddad behövs även lösenordet fyllas i för gå med i kursen. En

student kan välja att ångra sig genom att klicka på knappen ”Cancel & Return”. En användare som

valt att gå med i en kurs erhåller ett responsmeddelande enligt figur 3.18.

21

Figur 3.17: Gå med i kurs.

Figur 3.18: Gå med i kurs meddelande.

22

Figur 3.19: En students gränssnitt för att lämna in en laboration.

När en student anländer till sidan ”Visa labb” visas namnet på kursen som laborationen tillhör som

huvudrubrik följt av laborationens namn som underrubrik och laborationens beskrivning.

Studenten visas en lista av den utmatning som förväntas av laborationen, som följd av motsvarande

inmatning. En student kan välja att söka efter sin laboration som ska lämnas in på en lokal enhet

genom att klicka på knappen ”Browse”, när studenten valt en fil visas filnamnet. När en student

vill bekräfta inlämningen av zipfilen klickar studenten på ”Upload”. En användare kan istället för

att ladda upp en zipfil välja att klistra in koden i en textbox. När användaren klistrat in koden och

vill bekräfta uppladdning ska användaren klicka på knappen ”Submit Code”. Då användaren inte

vill lämna in en laboration kan användaren klicka på knappen ”Cancel & Return”. När knappen

”Upload” eller ”Submit Code” klickats visas en sida som anger att rättning pågår (se figur 3.20).

Då laborationen rättats visas ett resultat enligt figur 3.21. Resultatet kan vara antingen godkänt

eller ett meddelande som anger varför laborationen inte godkändes.

23

Figur 3.21: Inlämnad labb resultat/meddelande.

Figur 3.20: Inlämnad labb vänta på rättning.

24

Figur 3.23: Förenklad webbapplikation server flödesfigur.

Figur 3.22: Överskådlig bild av Autolab.

3.2 Detaljerad design

Autolab som helhet består av fyra logiska komponenter: en användarklient, vilken representerar en

användare som önskar använda Autolab, en webbapplikationsserver vilken presenterar och tillåter

åtkomst till Autolab för en användarklient, en databas innehållande informationen om de objekt

Autolab är uppbyggt kring och slutligen en inlämningsserver vilken hanterar rättning och

plagiatkontroll.

Figur 3.23 ger en schematisk bild av informationsflödet i webbapplikationsservern. Tidigare

gränssnittet i Autolab, gränssnittet binds samman med den logik som krävs via en vy och logiken

appliceras på objekt inom den databas som presenteras i figur 3.22.

25

Figur 3.24: Överblick av samlingarna inom Autolab databasen.

Autolab är uppbyggt kring fyra objekt: användare, kurser, laborationer samt inlämningar där varje

objekt består av ett antal attribut vilka representeras av varsin samling (eng. ”collection”) inom en

databas (se figur 3.22). En kurs kan ha en eller flera laborationer. En användare kan vara aktiv

inom en eller flera kurser och utföra samt bli godkänd för kursens laborationer i form av

inlämningar. En inlämning är en laboration som utförts av en användare. Som visas i figur 3.24, så

lagras de fyra huvudobjekten i Autolab i separata samlingar i Autolabs databas och samlingarna

kommer följande att förklaras översiktligt.

Objekt inom samlingen användare (”Users”) är uppbyggda genom att ha en unik identifierare

(”_id”) som primärnyckel. Objekten har också följande attribut: användarnamn (”username”),

födelsenamn (”realname”), e-mejladress (”email”) samt senaste aktivitet via inloggning

(”lastlogin”). Utöver det har en användare ett lösenord (”password”) för att logga in till Autolab.

Användarens nivå är det som avgör om användaren är en lärare eller student och representeras av

en användarnivå (”userlevel”). Vidare kan en användare ha ett antal kurser (”courses”) inom vilken

användaren är aktiv, dessa kurser motsvarar en identifierare av kursobjekt. Slutligen finns ett

attribut som agerar som ett laborationskvitto (”labsdone”) vilken sparar identifierare för samtliga

korrekt utförda laborationer.

26

Objekt inom samlingen kurser (”Courses”) är uppbyggda genom att ha en unik identifierare (”_id”)

som primärnyckel. Objekten har också följande attribut: kursnamn (”name”), kurskod (”code”),

termin (”term”) samt en valfri kursförklarande text (”text”). Utöver det kan en kurs ha ett lösenord

(”password”) för att en användare ska kunna gå med i kursen. Vidare har kurser en binär indikator

som anger om en kurs är aktiv eller arkiverad i form av attributet arkiverad (”archived”).

Avslutningsvis kan kurser ha ett godtyckligt antal laborationer (”labs”) vilket motsvarar en

identifierare för de laboration objekt som tillhör en kurs.

Objekt inom samlingen laborationer (”Labs”) är uppbyggda genom att ha en unik identifierare

(”_id”) som primärnyckel. Objekten har också följande attribut: laborationsnamn (”name”),

laborationförklarande text (”text”), programspråk (”language”), svårighetsnivå (”level”) samt

förväntad tidsåtgång (”time”) för laborationen. Vidare har laborationer en binär indikator som

anger om en laboration är aktiv eller arkiverad (”archived”). Avslutningsvis kan laborationer ha ett

attribut för att beskriva till vilka kurser (”courses”) den specifika laborationen är aktiv inom i form

av identifierare för kursobjekt.

Objekt inom samlingen inlämningar (”Submissions”) är uppbyggda genom att ha en unik

identifierare (”_id”) som primärnyckel. En inlämning består av ett antal attribut vilka förklarar

inlämningen i form av ett användarid (”userid”) där attributet användarid är en identifierare för

motsvarande användarobjekt som utförde inlämningen av laborationen. En inlämning har ett

laborationsid (”labid”) där attributet laborationsid motsvarar en identifierare för motsvarande

laborationobjekt och är den inlämnade laborationen. Attributet status (”status”) är en binär flagga

och beskriver om inlämningen är klassad som godkänd eller inte. En inlämning sparar all

information om inlämningen i form av den kod eller innehållet i de filer som lämnats in inom

attributet filer (”files”), attributet fingerprint (”fingerprint”) sparar nyckelord från den kod som

existerar inom attributet filer. Slutligen består objektet inlämning av ett plagieringsattribut

(”plagiate”) vilket motsvarar en lista av de tidigare inlämningar från andra användare som den

aktiva inlämningen är ett misstänkt plagiat av.

27

Autolab använder sig av en enskild server för att hantera inlämningar av laborationer från

användare. Figur 3.25 beskriver övergripande hur processen av en inlämnad laboration går till,

processen börjar med att en användare lämnar in en laboration i form av en inlämning.

Laborationen kompileras och producerar en exekverbar fil. Den resulterande exekverbara filen

körs och dess resultat jämförs i evaluering med de parametrarna som satts för en godkänd

laboration. När en inlämnad laboration är godkänd utförs en plagiatkontroll på laborationen där

antingen en flagga sätts för att markera misstänkt plagiat eller inte, oavsett utfall från

plagiatkontrollen är laborationen markerad som godkänd och användaren meddelas om det

godkända resultatet. Figur 3.25 visar en alternativ väg för de tre faserna ”Kompilering”,

”Exekvering” och ”Evaluering” vilket är de alternativa fall då något av stegen misslyckas vilket

resulterar i ett felmeddelande som respons till användaren.

28

Figur 3.25: Inlämning flöde till inlämning servern.

Figur 3.26: Användningsfall inom Autolab

I presentationen av gränssnittet inom avsnitt 3.1 listades Autolabs primära användningsfall. Figur

3.26 är en sammanfattning av dessa användningsfall. I den följande texten kommer vi att i mer

detalj beskriva respektive användningsfall i form av tid-sekvensdiagram där aktörerna är

gränssnittet i form av en aktiv användare, den vy som binder samman gränssnittet och logiken,

logiken för objektet och slutligen databasen vilken bistår med lagringen av objektet.

29

Figur 3.27: Visa ett objekt.

Figur 3.28: Lägg till ett objekt.

Presentation av objekt inom Autolab följer samma tillvägagångssätt. Figur 3.27 presenterar

processen i form av ett tid-sekvens diagram. Figur 3.27 visar en användare inom gränssnittet som

valt att visa ett objekt inom Autolab vilket medför att funktionen show() anropas inom ett objekts

vy. Funktionen show() inom vyn fastställer identifieraren för objektet som önskas visas och

anropar funktionen fromid() inom objektets logik. Funktionen fromid() finner objektet inom

databasen via identifieraren och extraherar objektets information från databasen för att sedan

omvandla och returnera informationen för objekt så att informationen kan presenteras för

användaren i gränssnittet.

Figur 3.28 visar tid-sekvensdiagrammet för användningsfallet ”Lägga till ett objekt”. En användare

inom gränssnittet som valt att lägga till ett objekt inom Autolab vilket medför att funktionen add()

anropas inom ett objekts vy. Funktionen add() inom vyn extraherar informationen från formuläret

och anropar funktionen add() inom logiken för objektet med formulärinformationen. Funktionen

add() inom logiken lägger till det nya objektet med attribut enligt formulärinformationen till

databasen och returnerar sedan en identifierare för det objektet som adderades till databasen. Sedan

följer att visa det tillagda objektet som tidigare beskrivet i figur 3.27.

30

Figur 3.30: Arkivera ett objekt.

Figur 3.29 visar tid-sekvensdiagrammet för användningsfallet ”Uppdatera ett objekt”. En

användare inom gränssnittet som valt att visa ett objekt inom Autolab vilket medför att funktionen

show() anropas inom ett objekts vy. Funktionen show() inom vyn fastställer identifieraren för

objektet som önskas visas och anropar funktionen fromid() inom objektets logik. Funktionen

fromid() finner objektet inom databasen via identifieraren och extraherar objektet och returnerar

det till vyn för objektet. Inom vyn anropas nu logiken på nytt via funktionen update() där det

extraherade objektet uppdateras med den nya informationen och lagrar den uppdaterade

informationen i databasen via databasfunktionen update(). Det uppdaterade objektet presenteras

sedan som tidigare nämnt enligt figur 3.27.

Tid-sekvensdiagrammet för arkivering enligt figur 3.30 fungerar på exakt samma vis som

uppdatering inom Autolab beskrivet ovan i figur 3.29, med undantaget att informationen av

objektet som uppdateras inom databas är enbart attributet arkiverad för att markera att objektet är

arkiverat.

31

Figur 3.29: Uppdatera ett objekt.

Tid-sekvensdiagrammet för att en student ska gå med i en kurs enligt figur 3.31 fungerar till stor

del som uppdatering inom Autolab vilket är beskrivet ovan i figur 3.29. Undantagen är att det

enbart gäller för användare av typen student samt den informationen av objektet som uppdateras

för studenten är attributet kurser vilket beskriver kurser användaren gått med i och vidare att det

potentiellt krävs ett lösenord.

Processen för en student vid inlämning av en laboration inom Autolab presenteras i figur 3.32.

Figur 3.32 visar en student som lämnat in en laboration vilket medför att funktionen submit()

anropas inom vyn, först extraheras informationen om vilken laboration det rör sig om som

beskrivet i tidigare figurer där fromid() finner laborationen i databasen och returnerar den till

objektets vy. Objektets vy anropar nu funktionen submit() inom logiken där studentens inlämnade

kod läggs till i databasen via insert() tillsammans med informationen om laborationen. Det skapas

också en mapp med den kod och potentiella filer som studenten lämnat in i väntan på

inlämningsservern som beskrivet i figur 3.25.

32

Figur 3.32: Lämna in en laboration.

Figur 3.31: Gå med i en kurs.

Figur 3.33 visar en användare inom gränssnittet som valt att visa en lista av objekt inom Autolab

vilket medför att funktionen list() anropas inom ett objekts vy. Funktionen list() inom vyn

fastställer vilken formulärinformation som bifogats för att avgöra om en användare gjort en

sökning och i så fall vad för sökning, vidare fastställer funktionen vilken sida i listan som ska

visas. När list() fastställt detta anropas funktionen getrange() inom objektets logik. Funktionen

getrange() finner samtliga objekt inom databasen baserat på potentiella sökparametrar och

extraherar dessa objekt för att sedan genomföra en paginering för att motsvara den aktiva sidan

som ska visas i gränssnittet. Sidan med objekt returneras till vyn för objektet. Inom vyn anropas nu

logiken på nytt via funktionen count() där logiken fastställer det maximala antalet sidor som är

möjligt efter de parametrar som satts genom att räkna antalet objekt i databasen och returnerar

resultatet i form av ett nummer. Den aktiva sidan som returnerats renderas inom gränssnittet

tillsammans med information för att presentera en korrekt representation av antalet möjliga sidor.

33

Figur 3.33: Listning av objekt.

Figur 3.34: Plagiatkontroll flöde för en inlämning.

I Autolab genomgår en inlämning en process för att för att kontrollera om inlämningen är ett

misstänkt plagiat av en annan students tidigare inlämning inom en kurs. Figur 3.34 visar flödet för

en enkel version av plagiatkontroll som existerar inom Autolab, figuren visar att en inlämning

extraheras från databasen och används inom plagiatkontrollen. Plagiatkontrollen parsar ut koden

från inlämningen och jämför den mot koden från tidigare inlämningar inom kursen. Jämförelsen

mellan två koder består av att jämföra om de två kodsträngarna är identiska. I de fall kodsträngarna

är identiska uppdateras plagiatattributet med identifierare för den inlämning vilken är ett misstänkt

plagiat.

34

Figur 3.35: Plagiatkontroll flöde för en inlämning.

Figur 3.35 beskriver en mer avancerad plagiatkontroll som existerar inom Autolab. Likt den

enklare plagiatkontrollen i figur 3.34 är flödet att extrahera en inlämning från databasen, utföra en

plagiatkontroll samt uppdatera databasen med resultat om misstänkt plagiat från plagiatkontrollen.

Skillnaden är att plagiatkontrollen utökats från att jämföra två kodsträngar till att gå igenom en

egen intern process bestående av faserna normalisering, algoritm och evaluering. Normaliserings

syfte är att tillåta plagiatkontrollen att upptäcka mer avancerade former av plagiat. Algoritmen är

Rabin-Karp beskrivet i kapitel 2 med några modifikationer för att bistå normaliseringen.

Avslutningsvis inkluderas en evaluering för att ge en mer fri tolkning av resultatet från algoritmen.

Plagiatkontrollen kommer följande att beskrivas mer ingående genom att gå igenom och förklara

faserna från figur 3.35.

Normaliseringen för plagiatkontrollen beskrivs i figur 3.36. I figuren visas flödet från det att en

laboration lämnas in. De filer som innehåller kod från inlämningen väljs ut genom att identifiera

filtyp, innehållet från dessa filer sammanfogas till en sträng motsvarande filinnehåll. Filinnehållet

tillsammans med regler används som inmatning till PLY-lexern vilken baserat på regler skapar en

utström av nyckelord från filinnehållet. Nyckelorden samlas sammanfogade i en sträng, strängen

35

Figur 3.36: Normalisering för plagiatkontrollen.

uppdaterar attributet fingerprint för inlämningen samt används som inmatning till algoritmen.

Reglerna som visas i figur 3.36 används som beskrivet ovan för att upptäcka och parsa ut

nyckelord från filinnehåll. Filinnehållet är i form av kod i programspråket C vilket för nuvarande

är det enda programspråk Autolab stöder. Reglerna baserar sig på grundreglerna i C99 till PLY-

lexern [20] för parsning av programspråket C men reglerna innehåller modifikationer för att

anpassa sig till att hitta eftertraktade nyckelord till algoritmen för att detektera olika former av

plagiat. De former av plagiat som reglerna förväntas detektera är när en plagiatör har: kopierat en

annan individs kod rakt av utan modifikation, bytt identifieringsnamn för variabler och funktioner,

ersatt typ av variabel, iterator eller operation, inkluderat kommentarer eller utskrifter oväsentligt

för kodens funktionalitet, kastat om flödesordningen som programmet exekverar i utan att påverka

programmets funktionalitet. För att uppfylla det innehåller reglerna samlingsnyckelord för samtliga

typer (TYP), iteratorer (ITE), urval (CHO), operatorer (OPE) samt tilldelningar (ASS) för att inte

göra skillnad på kod som fyller samma funktion. Reglerna förkastar samtliga variabelnamn,

magiska nummer, utskrifter samt kommentarer då de inte är relevanta för resultatet av en

exekverad inlämning.

Figur 3.37 visar en inlämning vilken genomgått en normalisering, i figuren kan översättningen från

kod till nyckelord (eng. fingerprint) baserat på de regler som satts upp ses. Bibliotek, utskrifter, nya

rader, mellanslag och avgränsningstecken förkastas. Fyra typer (TYP) detekteras för int objekten a

och b, double objektet c samt funktionen main() av returneringstyp int. Fem till tilldelningar (ASS)

detekteras från a = 10, b = 5, c = 0.00, b = b + c, samt b = b+a. Två urval (CHO) detekteras if(b <

c) och if (a ==a). Fyra operationer (OPE) detekteras, (b < c), c++, (a == a), (c < a). En iterator

(ITE) while. Samtliga nyckelord ses i strängen fingerprint sorterade.

36

Figur 3.37: Exempel på en inlämning som genomgått normalisering.

Figur 3.38: Algoritm för plagiatkontroll.

Figur 3.38 visar algoritmfasen i plagiatkontrollen, Rabin-Karp som nämnd i kapitel 2 tar en text

samt en samling substrängar och kontrollerar om substrängarna finns i texten. I implementationen

motsvarar strängen av nyckelord för inlämningen texten vilken skall kontrolleras. Substrängarna

utgörs av substrängar från en annan laborations nyckelordssträng. Det innebär att

implementationen undersöker hur stor del av en annan laborationsinlämning som är identisk med

den aktiva inlämningen samt returnerar samtliga substrängar som återfanns i inlämningen som

resultat. Proceduren repeteras med samtliga tidigare inlämningar som mönster. Inom algoritmen

Rabin-Karp har rolling hash (RollingHash) som beskrivet i kapitel 2 utvidgats, där tillåtelse att

motsvara nyckelord och mönster har implementerats.

Figur 3.39 visar hur implementationen av förlängningarna RollingWord och RollingPattern för

RollingHash fungererar, likt figuren visar ersätter RollingWord den ursprungliga RollingHash

funktionaliteten. Fönstret rör sig nu istället ord för ord genom strängen av nyckelord.

RollingHashPattern visar att vid en matchning av ett mönster så rör sig fönstret fram till nästa

potentiella mönster som kan matchas, vilket leder till att extra matchningar för samma kombination

av mönster inte längre sker.

37

Figur 3.39: Implementationen av RollingWord och RollingPattern.

För att påvisa att RollingHashWord är giltigt börjar vi med en variant för det kända fallet för

RollingHash. Där hashning i ett glidande fönster, tecken för tecken kan visualiseras. Varje tecken

hashas separat och adderas till en hashsumma som representerar fönstrets hela hashvärde.

Hashningen sker enligt formeln: H= hash(c1) + hash(c2) + … + hash(cn).

H är det totala hashvärdet för fönstret, c# är den individuella bokstaven inom fönstret som

hashoperationen utförs på, där numret # representerar bokstavens position och n är totala antalet

bokstäver inom fönstret och därmed också längden av fönstret.

För att beskriva att fönstret rör sig tecken för tecken med samma formel där fönsterlängden är 9. H

består då av de nio bokstäverna c1, c2, c3, c4, c5, c6, c7, c8, c9. Den följande bokstaven i texten som

fönstret glider över är då index i c10. Det resulterar i formeln för det nya hashvärdet som beskriver

att fönstret rört sig ett tecken:

H = hash(c1) + hash(c2) + hash(c3) + hash(c4) + hash(c5) + hash(c6) + hash(c7) + hash(c8) +hash(c9)

H = H – hash(c1) + hash(c10)

Utvidgningen till RollingHashWord bygger då vidare på samma exempel genom att använda sig av

nyckelord bestående av enskilda bokstäver enligt:

Nyckelord1 = c1, c2, c3 , Nyckelord2 = c4, c5, c6, NyckelordY = cx-2, cx-1, cx.

Där Y motsvarar antal Nyckelord inom texten, resulterar i att fönstret i hashform rör sig enligt:

H = hash(Nyckelord1) + hash(Nyckelord2) + hash(Nyckelord3)

H = H – hash(Nyckelord1) + hash(Nyckelord4)

Vilket visar att hashvärdet H håller sig enligt tidigare RollingHash funktionalitet och att det enbart

är fall där fönstret omöjligt kan matcha ett mönster som faller ifrån.

38

Evalueringen för plagiatkontrollen visas i figur 3.40, där resultatet från algoritmen innehåller en

lista av de mönster som återfanns i inlämningen. Resultatet jämförs med de ingående mönstren, i

de fall samtliga mönster återfanns inom inlämningen och de båda inlämningarna innehöll samma

antal nyckelord flaggas inlämningen som ett suspekt plagiat i databasen för inlämningen.

4 Evaluering och utvärdering

Detta kapitel går igenom några av de tester som utfördes på Autolab. Fallen innefattar de

användningsfall som beskrivits samt de plagiatkontroller som implementerats.

Fall 1. Testet kontrollerar implementationen för listning av objekt, sökning inom listan och

paginering. Förväntat resultat är att samtliga objekt som existerar i databasen ska representeras i

listan. När ett sökord används förväntas att enbart objekt innehållande sökordet visas i listan. Ett

sökord ska inte ta hänsyn till bokstavsstorlek eller mellanslag. När ett sökord och filtervärde

används förväntas att enbart objekt innehållande sökordet för det valda filtervärdet visas i listan.

Pagineringen ska fungera för samtliga ovan nämnda alternativ. Testet utfördes genom att fylla

databasen med fingerade användare och inom användargränssnittet gå igenom listan och jämföra

den mot databasen för att bekräfta att samtliga användare visas. Vidare i användargränssnittet

användes sökord och filtervärden i olika kombinationer och granskning av resultatet för att

bekräfta att det var den önskade funktionaliteten.

39

Figur 3.40: Evaluering för plagiatkontroll

Fall 2. Testet kontrollerar implementationen för att visa och uppdatera en användare. Förväntat

resultat är att när en länk för att visa en användare klickas i användargränssnittet ska den valda

användaren visas med tillhörande attribut. Då länken för att uppdatera användaren klickas ska

attributen tillåtas att ändras och vid bekräftad ändring ska databasen uppdateras med de ifyllda

värdena och användaren ska visas med de nya värdena när en länk klickas för att visa användaren.

Testet utfördes genom att i användargränssnittet utföra den ovan nämnda proceduren för att

bekräfta funktionaliteten samt granska att databasen gav rätt information samt uppdaterades

korrekt.

Fall 3. Testet kontrollerar implementationen av arkivering. Förväntat resultat är att när ett objekt

arkiverats så exkluderas objektet från listor vid sökning i de normala fallen för en användare.

Objektet ska vara intakt i databasen. En student ska inte längre kunna gå med i en arkiverad kurs.

Kurser och laborationer som arkiverats ska fortfarande visas inom en students användargränssnitt

om studenten var aktiv inom den kursen samt laborationen innan någon av dessa arkiverades. En

lärare ska genom specifik sökning kunna finna arkiverad information. Testet utfördes genom att i

användargränssnittet prova och bekräfta funktionaliteten.

Fall 4. Testet kontrollerar implementationen av den plagiatkontroll som innebär en direkt

strängjämförelse mellan två inlämningar. Förväntat resultat är att en direkt plagiering av en tidigare

inlämning ska resultera i att databasen lägger till identifieraren av den misstänkta inlämningen till

listan av plagiat. Då en inlämning är misstänkt för ett plagiat ska det kunna visas i

användargränssnittet där koden från inlämningarna kan jämföras mot varandra. Testet utfördes

genom att göra en enkel ”Hello World!” inlämning för en laboration, följt av att göra en till

identisk inlämning samt en annorlunda inlämning som utnyttjade en annan print funktion.

Resultatet granskades i databasen samt användargränssnittet för att bekräfta funktionaliteten.

40

Figur 4.01: En inlämning.

Figur 4.02: En plagierad inlämning.

Fall 5. Testet kontrollerar implementationen av plagiatkontrollen vilken innehåller faserna

normalisering, algoritmen Rabin-Karp samt evaluering för ett syntetiskt test. Förväntade resultatet

för varje fas är: Inom normaliseringen ska koden från en inlämning omvandlas till en sträng av

nyckelord. Inom algoritmen ska inmatningen i form av nyckelordssträngen från normalisering samt

samlingen av mönster motsvarande en identiskt inlämning som nyckelordssträngen ska jämföras

emot hashas korrekt samt utföra en genomlöpning av mönsterdetektering. Evaluering ska upptäcka

att det troligen rör sig om en identisk inlämning och det ska resultera i att databasen lägger till

identifieraren av den misstänkta inlämningen till listan av plagiat. Normaliseringen undersöktes

genom att vid inlämningar se om normaliseringen stämde överens med reglerna som beskrivs i

kapitel 3. Inlämningen efter reglerna är demonstrerat i figur 4.01 som visar att nyckelord för

samtliga typer (TYP), iteratorer (ITE), urval (CHO), operatorer (OPE) samt tilldelningar (ASS)

upptäcks och omvandlas.

En andra inlämning utfördes där den första inlämningens kod kopierats men modifierats.

Modifikationen innebar metoder som används vid plagiering i form av att: byta identifieringsnamn

för variabler, ersätta variabeltyper, byta iteratorer samt operationer, inkluderat kommentarer och

utskrifter oväsentligt för kodens funktionalitet samt slutligen kastat om flödesordningen enligt

figur 4.02.

41

Figur 4.02 visar att den andra inlämningen genomgår normaliseringen vilken parsar ut

nyckelorden. Den andra inlämningen genomgår sedan algoritmen vilken utför hashningen och

fönstret glider igenom texten och matchas mot mönstren, i varje steg av RollingWord upptäcks en

matchning och matchningen bekräftas i hashvärde samt klartext. Algoritmen returnerar listan med

matchade mönster och evalueringen upptäcker att samtliga mönster är matchade och att det rör sig

om en liknande inlämning och markerar därmed misstanke för plagiat. Plagiatkontrollen är

fungerande för fall där två laborationer är efter plagiatkontrollens regler identiska, kontrollen

täcker därmed samma område som den enklare direkta strängmatchningsalgoritmen med

fördelarna att även ta hänsyn till att upptäcka plagiat som inte en direkt strängjämförelse klarar av.

Nackdelen är att en lärare kommer behöva avgöra fler fall då det rör sig om falska positiva resultat

av evalueringen.

Fall 6. Testet kontrollerar plagiatkontrollen vilken innehåller faserna: normalisering, algoritmen

Rabin-Karp samt evaluering för ett reellt test av laborationer från en kurs i dataalgoritmer. Testet

följer samma procedur som fall 5, där skillnaden är innehållet i koden. Det förväntade resultatet är

att algoritmen ska fungera likt fall 5 och flagga misstänkta plagiat. Vid utförandet av det reella

testet visade plagiatkontrollen svagheter, då laborationen utgjordes av en existerande kodbas vilket

innebar att samtliga laborationer var väldigt lika och enbart små justeringar skulle utföras av

studenterna. Vidare visades en svaghet att de typer och klasser vilka inte var med i C99 regelverket

inte kunde uppfattas som nyckelord av normaliseringen. Slutligen visar testet att den direkta

evalueringen av resultatet inte passar sig i det här fallet. En evaluering som utgick från en grad av

likhet samt ett tröskelvärde där avgörandet att när tröskelvärdet passeras klassas inlämningen som

misstänkt hade varit bättre. Några justeringar som kan utföras för plagiatkontrollen för framtiden

för att lösa de svagheter som upptäcktes inom testerna innefattar: Tillåta att användare kan

definiera de nyckelord som ska väljas ut inom reglerna för normaliseringen, det tillåter att flera

språk kan utnyttjas av plagiatkontrollen samt tillåter att användardefinerade klasser och strukturer

upptäcks. Tillåta att användare skickar in en text vilken ska ignoreras vid plagiatkontrollen, det

tillåter att laborationer som anländer med en redan definierad kod inte flaggas av plagiatkontrollen

att stora delar av kod mellan studenter är lika. Ge lärare möjlighet att via gränssnittet välja genom

vilka parametrar en laboration ska evalueras för plagiat. Att vid granskning av laborationer

misstänkta plagiat inom gränssnittet markera den kod vilken är misstänkt, underlätta för lärare att

finna det misstänkta plagiatet.

42

5 Slutsats

Vid projektets slut har många av de mål som sattes upp vid projektets start uppnåtts, vissa mål

uppnåddes delvis och en del mål uppnåddes inte då avgränsningar behövde utföras på grund av den

tid som återstod. Målet att utöka programspråken som Autolab hanterar förkastades på grund av

tidsbrist. Målen som rörde funktionalitet för typer som användare, kurser, laborationer och

inlämningar uppnåddes efter målbeskrivningen. Lärare har nu möjligheten att hantera användare

inom Autolab genom att kunna visa användare i en lista i användargränssnittet. Lärare kan nu visa

enskilda användare och kan även revidera användare. Laborationer har separerats från kurser och

agerar som övriga objekttyper inom Autolab. Samtliga systemets laborationer kan nu listas och

listan kan nås från en kurs eller separat utanför en kurs. Laborationer kan skapas direkt till listan

utan en bindning. Till systemets samtliga listor för kurser, laborationer och användare utfördes en

lyckad implementation av en sök- och filtreringsfunktion vilken tillåter att användare inom

systemet har en bättre möjlighet att finna information. Kod arkitekturen för användare, kurser och

laborationer har gjorts så lika att de kan beskrivas av samma tid-sekvensdiagram. Studenter kan nu

lämna in hela projekt i form av en zipfil, systemet lyckas identifiera filerna och skapa en makefil

vilken kan exekveras av inlämningsservern som utför en korrekt rättning. Kurser och laborationer

kan nu väljas att arkiveras, vilket innebär att de inte tas bort från systemet men att de döljs för

användare i systemet, vilket effektivt agerar som en borttagning. En plagiatkontroll vilken

omvandlar inlämningar och jämför strängvärden samt markerar misstänkt plagiat är implementerat.

Möjlighet för lärare att granska misstänkta plagiat har delvis implementerats, där möjligheten att

jämföra inlämningarna existerar men säkerhetskontroller saknas för de fall inlämningar försvinner

från systemet. En granskning av algoritmer vilka kan utföra en mer robust kontroll av plagiat har

utförts och algoritmen Rabin-Karp har implementerats tillsammans med en normalisering av indata

och evaluering av utdata. Den robusta plagiatkontrollen har möjlighet att avgöra om ett exakt

plagiat av en tidigare inlämning utförts, detta likt den enklare formen. Den robusta

plagiatkontrollen utvidgar den enklare genom att inte påverkas av vanliga knep plagiatörer utför

som att: byta identifieringsnamn för variabler och funktioner, ersätta typ av variabel, iterator eller

operation, inkludera kommentarer eller utskrifter oväsentligt för kodens funktionalitet, kasta om

flödesordningen som programmet exekverar i utan att påverka programmets funktionalitet. Vad

den robusta plagiatkontrollen saknar är att kunna känna igen användardefinerad information så

som klasser och typer som ska omvandlas till nyckelord, evaluera långa operationer som fyller

43

samma funktion som en kort operation, korrekt ignorera val av bibliotek. Evalueringen tillåter inte

en användare att via användargränssnittet välja graden av likhet mellan två inlämningar som ska

klassas som ett misstänkt plagiat. Lösningar för framtiden till de begränsningarna innefattar:

Tillåta att användare kan definiera de nyckelord som ska väljas ut inom reglerna för

normaliseringen, det tillåter att flera språk kan utnyttjas av plagiatkontrollen samt tillåter att

användardefinerade klasser och strukturer upptäcks. Tillåta att användare skickar in en text vilken

ska ignoreras vid plagiatkontrollen, det tillåter att laborationer som anländer med en redan

definierad kod inte flaggas av plagiatkontrollen då stora delar av kod mellan studenters

inlämningar är lika. Ge lärare möjlighet att via gränssnittet välja genom vilka parametrar en

laboration ska evalueras för plagiat. Att vid granskning av laborationer misstänkta för plagiat inom

gränssnittet markera den kod vilken är misstänkt och på så vis underlätta för lärare att finna det

misstänkta plagiatet. Implementationen möjliggör också valet att enkelt byta algoritm på grund av

hur faserna är uppbyggda, exempelvis rekommenderas algoritmen Winnowing att testas.

Det ingick flertalet tidskrävande moment under projektet bl.a. att sätta sig in i ett system vilket

saknade dokumentation och att sätta sig in i nya tekniker för att kunna förstå och påbörja

utvecklingen av systemet. Byte av utvecklingsmiljö blev också en tidförlust då systemet inte var

anpassat för en ny miljö och i det skedet av projektet saknades kunskap för att modifiera systemet

till den nya miljön, men med handledarens hjälp löstes det. Vid utveckling av koden uppstod också

flertalet småproblem då det var svårt att ta hänsyn till all den existerande koden vilket resulterade i

en hel del misstag. Projektet erbjöd utöver det personliga lärdomar: att få bekanta sig med en

etablerad kodbas i ett nytt programspråk med tillhörande ramverk och bibliotek, uppleva en

NoSQL [20] databasuppbyggnad samt få inblick i det plagieringsproblem som existerar och design

av potentiella lösningar kändes vid sammanfattningen av arbetet tillfredsställande. Det var

intressant att förhålla sig till och skapa förståelse för existerande kod och försöka utforma

lösningar genom diskussion för att behålla en enhetlig kod arkitektur i systemet. Den viktigaste

lärdomen som tas med är vikten av att planera arbete och skapa en rimlig tidsplan inledningsvis

inom ett projektarbete och att göra avvägningar samt avgränsningar. Avslutningsvis vill jag tro att

projektet har varit givande för att kunna förstå och hantera en verklig arbetsmiljö i framtiden.

44

Framtida arbete för Autolab innebär som tidigare nämnt att utvidga antalet programspråk systemet

kan hantera. Som ovan nämnt kan plagiatkontrollen utvecklas vidare och en jämförelse kan utföras

mellan olika algoritmer. Ett intressant område som bör utforskas mer är att gå in i en fördjupning

om vad och hur ett plagiat bäst bör tolkas inom ramen av systemets användningsområde och

utifrån resultatet forma evalueringen av plagiatkontrollen för att producera så få falska positiva

resultat som möjligt utan att skapa falska negativa resultat. Antalet komprimerade filtyper som

innehåller studenters program som ska evalueras kan utvidgas från zipfiler till att inkludera flera

komprimeringsformat. För systemets användargränssnitt finns det utrymme för förbättring.

Förslagsvis sker en utveckling av användargränssnittet med riktiga studenter och lärare som

användare för att skapa en effektiv återkoppling mellan utvecklare och användare och på så vis få

information om vad som saknas eller hur strukturen bör ändras för att underlätta användningen. En

ny användarnivå kan implementeras i form av en administratör för att särskilja behörighet mellan

vanliga lärare och lärare som ansvarar för mer avancerade funktioner i systemet, till

administratören kan en undersökning utföras om vilka administratörsverktyg som bör vara en

administratör till hands och utföra en implementation av dessa. Det stora testet för Autolab är att ta

systemet från en prototyp i utvecklingsmiljö till att fungera i dess tänkta miljö som ett aktivt

undervisningsverktyg.

45

Referenser

[1] Carrol, J., Zetterling, C-M., (2009). Hjälp studenterna att undvika plagiering. Kungliga

Tekniska Högskolan. [online] Available at:

https://www.kth.se/polopoly_fs/1.656371!/Hjalpstudenterna%20att%20undvika%20plagiering.pdf

[Accessed 12 Oct. 2017].

[2] Python.org. (2017). What is Python? Executive Summary. [online] Available at:

https://www.python.org/doc/essays/blurb/ [Accessed 12 Oct. 2017].

[3] Flask.pocoo.org. (2017). Welcome to Flask — Flask Documentation (0.12). [online] Available

at: http://flask.pocoo.org/docs/0.12/ [Accessed 12 Oct. 2017].

[4] MongoDB. (2017). What Is MongoDB?. [online] Available at:

https://www.mongodb.com/what-is-mongodb [Accessed 12 Oct. 2017].

[5] Groups.engin.umd.umich.edu. (2017). The HTML Programming Language. [online] Available

at: http://groups.engin.umd.umich.edu/CIS/course.des/cis400/html/html.html [Accessed 12 Oct.

2017].

[6] Jinja.pocoo.org. (2017). Welcome | Jinja2 (The Python Template Engine). [online] Available at:

http://jinja.pocoo.org/ [Accessed 12 Oct. 2017].

[7] Malmi, L., Korhonen, A., and Saikkonen, R., (2002). Experiences in automatic assessment on

mass courses and issues for designing virtual courses. [online] Available at:

https://dl.acm.org/citation.cfm?id=544433 [Accessed 12 Oct. 2017].

[8] Suleman, H. (2008). Automatic marking with Sakai. [online] Available at:

https://www.researchgate.net/publication/220803528_Automatic_marking_with_Sakai [Accessed

12 Oct. 2017].

46

[9] Ihantola, P., Ahoniemi, A., Karavirta, V., and Seppälä, O., (2010). Review of recent systems for

automatic assessment of programming assignments. [online] Available at:

https://www.researchgate.net/publication/216714976_Review_of_recent_systems_for_automatic_a

ssessment_of_programming_assignments [Accessed 12 Oct. 2017].

[10] Enström, E., Kreitz, G., Niemelä, F., Söderman, P., and Kann, V., (2011). 5 years with kattis

– using an automated assessment system in teaching, Kungliga Tekniska Högskolan. [online]

Available at: https://www.csc.kth.se/~gkreitz/kattis-fie11/kattis-fie11.pdf [Accessed 12 Oct. 2017].

[11] Karp, R., Rabin, M. (1987). IBM Journal of Research and Development ( Volume: 31, Issue:

2, March 1987 ). [online] Available at:

https://pdfs.semanticscholar.org/c47d/151f09c567013761632c89e237431c6291a2.pdf [Accessed

12 Oct. 2017].

[12] Massachusetts Institute of Technology, (2006). Rolling hash. [online] Available at:

http://courses.csail.mit.edu/6.006/spring11/rec/rec06.pdf [Accessed 12 Oct. 2017].

[13] Brilliant.org. (2017). Rabin-Karp Algorithm | Brilliant Math & Science Wiki. [online]

Available at: https://brilliant.org/wiki/rabin-karp-algorithm/ [Accessed 12 Oct. 2017].

[14] Brilliant.org. (2017). Knuth-Morris-Pratt Algorithm | Brilliant Math & Science Wiki. [online]

Available at: https://brilliant.org/wiki/knuth-morris-pratt-algorithm/ [Accessed 12 Oct. 2017].

[15] Brilliant.org. (2017). Boyer–Moore string search algorithm | Brilliant Math & Science Wiki.

[online] Available at: https://brilliant.org/wiki/boyer-moore-algorithm/ [Accessed 12 Oct. 2017].

[16] Safe-corp.com. (2017). SAFE Corporation - Plagiarism Detection System. [online] Available

at: https://www.safe-corp.com/products_codematch.htm [Accessed 12 Oct. 2017].

[17] S. Schleimer, D. S. Wilkerson, and A. Aiken. (2003). Winnowing: Local Algorithms for

Document Fingerprinting. [online] Available at:

https://theory.stanford.edu/~aiken/publications/papers/sigmod03.pdf [Accessed 12 Oct. 2017].

47

[18] Multimedia Information Networking and Security (MINES), (2010). International Conference

on Multimedia Information Networking and Security. [online] Available at:

http://ieeexplore.ieee.org/document/5671277/ [Accessed 12 Oct. 2017].

[19] Dabeaz.com. (2017). PLY (Python Lex-Yacc). [online] Available at:

http://www.dabeaz.com/ply/ply.html#ply_nn1 [Accessed 12 Oct. 2017].

[20] MongoDB. (2017). NoSQL Databases Explained. [online] Available at:

https://www.mongodb.com/nosql-explained [Accessed 18 Oct. 2017].

48

Appendix

49