autolab - diva-portal.se1151170/fulltext02.pdf · among other things, a simple plagiarism control...
TRANSCRIPT
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.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.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