Download Report

Digital tentamen på läsplattor
Digital exam on tablet computers
Adam Larsson
Carl Philip Matsson
Fakulteten för hälsa, natur- och teknikvetenskap
Datavetenskap
C-Uppsats 15 hp
Handledare: Martin Blom
Examinator: Donald Ross
Oppositionsdatum: 150602
Löpnummer:
Digital tentamen på läsplattor
Digital exam on tablet computers
Carl Philip Matsson
Adam Larsson
Sammanfattning
Syftet med detta projekt är att skapa en prototyp för ett digitalt tentamenssystem, där studenterna skriver tentamen med hjälp av läsplattor, samt
utvärdera vilka fördelar och nackdelar ett sådant system skulle kunna medföra.
Huvudfokuset för detta projekt var att utveckla en prototyp för ett digitalt tentamenssystem med stöd för bland annat automatisk rättning, kompilering och automatisk evaluering av programspråksfrågor. Vi försöker samtidigt bibehålla de positiva aspekterna av ett analogt system, som till exempel
möjlighet för både lärare och elev att uttrycka sig genom frihandsritning.
Denna studie har visat att det finns många fördelar för både studenter
och lärare med en övergång till ett digitalt tentamenssystem samt att man
med små medel kan skapa en fungerande prototyp av ett sådant system.
Innehållsförteckning
1 Introduktion
1.1 Syfte och mål . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Bakgrund
2.1 Introduktion . . . . . .
2.2 Tentamen idag . . . .
2.2.1 Lärarfördelar .
2.2.2 Studentfördelar
2.3 Befintliga system . . .
2.3.1 DigiExam . . .
2.3.2 Kattis . . . . .
2.3.3 Itslearning . . .
2.4 Sammanfattning . . .
3 Design
3.1 Introduktion . . . . .
3.2 Webbserver . . . . .
3.3 Android-applikation .
3.4 Kompileringsserver .
3.5 Databas . . . . . . .
3.6 Sammanfattning . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
.
.
3
3
3
5
6
7
8
9
10
11
.
.
.
.
.
.
12
12
14
15
16
16
18
4 Implementation
4.1 Introduktion . . . . . . . . . .
4.2 Webbserver . . . . . . . . . .
4.2.1 Lärarplattformen . . .
4.2.2 Kommunikationslänken
4.3 Android-applikation . . . . . .
4.4 Kompileringsserver . . . . . .
4.5 Databas . . . . . . . . . . . .
4.5.1 Exam . . . . . . . . .
4.5.2 Taken exam: . . . . . .
4.6 Sammanfattning . . . . . . .
5 Resultat
5.1 Introduktion . . . . . .
5.2 Skapande av tentamen
5.3 Tentamens-skrivande .
5.4 Rättning av tentamen
5.5 Sammanfattning . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Slutsats
6.1 Sammanfattning . . . . . . . . . . . . . .
6.2 Projektevaluering . . . . . . . . . . . . . .
6.3 Problem . . . . . . . . . . . . . . . . . . .
6.4 Vidareutveckling . . . . . . . . . . . . . .
6.4.1 Skapande och rättning av tentamen
6.4.2 Android-applikation . . . . . . . .
6.4.3 Kodkompileringsserver . . . . . . .
6.4.4 Säkerhet . . . . . . . . . . . . . . .
7 Appendix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
20
20
21
23
28
33
33
34
35
.
.
.
.
.
36
36
37
41
46
50
.
.
.
.
.
.
.
.
52
52
52
53
54
54
55
55
55
56
Kapitel 1
Introduktion
1.1
Syfte och mål
Syftet med detta projekt är att skapa en prototyp för ett digitalt tentamenssystem, där studenterna skriver tentamen med hjälp av läsplattor, samt
utvärdera vilka fördelar och nackdelar ett sådant system skulle kunna medföra.
Det finns redan idag ett flertal olika system som tillhandahåller tjänster
för digitala tentamina men det är inget, till vår vetskap, av dessa som tillhandahåller någon tjänst för att kompilera samt exekvera kod vilket är något
som uppdragsgivaren eftertraktar. De system som redan finns idag tillhandahåller heller inte alla de positiva aspekter som ett analogt system bidrar
till vilket är något vi kommer att sträva efter att bibehålla även i det digitala
systemet.
Uppdragsgivaren vill använda den prototyp samt den information detta
projektet kommer att generera för att visa på fördelarna med ett digitalt tentamenssystem och att de överväger kostnaderna som uppstår vid införande
av ett sådant system.
1
1.2
Disposition
I kapitel 2 beskriver vi hur en tentamen ser ut idag och vilka fördelar ett
digitalt system skulle kunna medföra för både lärare och studenter. Kapitlet
beskriver en del av de tjänster som idag tillhandahåller system för digitala
tentamina.
I kapitel 3 går vi igenom designen och strukturen bakom de olika komponenterna samt deras funktioner. Vi ger en överblick över hur de olika komponenterna samarbetar, kommunicerar och bidrar till ett fungerande tentamenssystem. Informationen redovisas med hjälp av bilder samt beskrivande
text och syftar till att ge läsaren en förberedande förståelse om hur systemet
fungerar i teorin vilket är fördelaktigt för att lättare förstå implementationen.
I kapitel 4 beskriver vi implementationen av de olika komponenterna i
systemet med hjälp av text, bilder och kodexempel. Vi ger en mer grundlig
beskrivning av hur de olika komponenterna fungerar.
I kapitel 5 presenteras resultatet av projektet. De olika komponenterna
visualiseras med hjälp av bilder och text för att ge en inblick i hur resultatet
blev och hur systemet kan användas i praktiken.
I kapitel 6 ger vi en evaluering av hur projektet har gått. Vi går även
igenom en del av de problem vi har haft under projektets gång samt hur
vi har löst dessa. Vi avslutar kapitel 6 med att gå igenom en del av de
potentiella möjligheterna som finns för att vidareutveckla detta system.
2
Kapitel 2
Bakgrund
2.1
Introduktion
Denna studie syftar till att utvärdera möjligheterna, fördelarna samt nackdelarna med att övergå till en digital form av tentamen istället för att tentera
på papper. Resultatet är intressant för uppdragsgivaren, Martin Blom vid
Karlstads universitet, då han vill inspirera och övertyga sina kollegor samt
investerare om att digitala tentamina är något som kommer spara tid, bidra
till mindre arbetsbelastning för examinatorerna vid tentamen, bidra till snabbare feedback till studenterna samt öka realismen, framförallt vid tentamina
inom datavetenskap, då man exempelvis kan kompilera kod under en tentamen. I avsnitt 2.2 beskrivs hur tentamen vid Karlstads universitet ser ut
idag och hur den skulle kunna förbättras för både studenter och lärare med
hjälp av en digitaliserad tentamen. I avsnitt 2.3 diskuteras redan befintliga
system och deras funktionalitet.
2.2
Tentamen idag
I dag skrivs en klar majoritet av alla tentamina vid Karlstads universitet i
skrivsal på papper. En tentamen skapas i regel av läraren för den aktuella
3
kursen via valfritt program på sin dator. När läraren har skapat sin tentamen
skickas den vidare för kopiering. Tentamen skrivs där ut och kopieras upp
till det antalet studenter som anmält sig till tentamen. Väl i skrivsalen delas
pappersarken ut till studenterna som för hand fyller i sin personliga information såsom anonymitetskod eller personnummer. När studenten har slutfört
sin tentamen samlas arken ihop och skickas tillbaka till läraren. Läraren
rättar tentamina för hand och ibland kan det handla om upp emot 180 studenter som skriver tentamen på en och samma kurs. När en tentamen är
rättad räknar läraren ihop poängen för tentamen och skickar den vidare för
att skannas in och rapporteras till Ladok.
Det är lätt att se att det finns flera fördelar för både lärare och studenter
med en digital tentamen men det kan också sparas väldigt mycket resurser på
den administrativa delen som till exempel kopiering av tentamina och andra
logistiska områden. I tabell 2.1 på sida 7 redovisas de steg som en tentamen
idag går igenom från planeringsstadiet till hantering och lagring av genomförd
tentamen och i flödesdiagrammet 2.1 jämförs ett digitalt system med dagens
system.
I förstudierapporten för elektronisk tentamen vid Karlstad universitet
kom man fram till att med en digital tentamen skulle man kunna spara 5767
arbetstimmar per år om man antar att man har 1600 tentamenstillfällen och
37196 tentamensplatser per år. [14]
Det vi hoppas kunna visa med denna studie är att det är möjligt att
eliminera många av dessa resurs- och tidskrävande faser som en tentamen
idag går igenom och som genom en digital tentamen blir obsoleta.
4
Fig. 2.1: Extra steg i en analog tentamen.
(Se tabell: 2.1 för ingående beskrivning av alla steg i en analog tentamen)
2.2.1
Lärarfördelar
Det finns många fördelar med ett digitalt tentamensystem för lärarna, där
en del är mer uppenbara än andra. En fördel med ett digitalt system är att
mycket av rättningen sker automatiskt. Flervalsfrågor och liknande frågor
5
kan mycket enkelt rättas av ett program och poängen summeras automatiskt
vilket både gör tentamen mer rättssäker, då det eliminerar risken för räknefel,
samt minskar arbetsbördan för läraren. Ett digitalt tentamensystem gör det
också lättare för läraren vid poängsättning då studentens svarsblad alltid är
korrekt sorterade och formaterade enligt given standard. Skapandet av en
tentamen kommer också att underlättas då detta kommer att göras genom en
hemsida med en inbyggd mall som skapar all struktur och layout för tentamen
automatiskt. En av de fördelar som man kanske inte tänker på är att läraren
kommer att kunna få tillgång till en tentamen direkt efter att studenten har
lämnat in den, istället för att vänta på att tentamen ska hanteras och till
slut skickas till läraren vilket kan bidra till snabbare retur av tentamina till
studenterna.
2.2.2
Studentfördelar
Även studenter kan få stor nytta med ett digitalt system. Det finns möjlighet
för studenter att snabbt få feedback på uppgifter då en applikation kan analysera vad studenten svarar och ge lämplig feedback. Ett exempel på detta
är koduppgifter där studenterna kan använda sig av en kompilera-knapp
för att kontrollera att koden är syntaktiskt korrekt och i vissa fall, enligt
lärarens specifikationer, även om koden exekverar och ger rätt svar enligt
fördefinierade testfall. Att ha tillgång till ett tangentbord ser många som en
fördel men det gäller inte för alla då vissa föredrar att skriva med penna och
papper. Andra studentfördelar innefattar bland annat att de slipper hantera
papper med allt vad det innebär såsom sortering, numrering och ange identifikation på varje ark. Då många av de logistiska delarna av hur tentamina
hanteras försvinner och mycket automatiseras, inte minst vid rättningen av
tentamina, så kommer studenterna få resultatet av tentamen snabbare än
tidigare.
6
Planering:
Transport och förvaring efter tentaskrivande:
Bokning av tentor
Transport av tentor till tentamenssamordningen
Publicering av tentatider
Förvaring samt hämtning av tentor
Planering av tentor, personal och lokaler
Hantering efter genomförd tenta:
Kopiering:
Sortering av tentor i nummerordning
Utkörning av skrivarpapper
Ta ut rättningsprotokoll
Beställning av tenta-förstasidor och tentaomslag
Lämna till lärare
Uppkopiering av tentor
Rapportera resultat i LADOK
Bladning av tentor
Skriva poäng på tentans förstasida
Skriva kartongbladet/arket
Ta bort tentaomslag
Transport och förvaring inför tentaskrivande:
Lämna till tryckeriet för borttagande av häftat hörn
Transport av tentor till tentamenssamordningen
Lämna till studentcentrum
Förvaring av tentor
Inscanning
Kontroll av tentor
Förvara i 24 månader
Transport av tentor till tentasal
Arkivera och publicera tentan i SIPS
Förbereda tentasal:
Bordsplacering
Hämta ev hjälpmedel såsom miniräknare
Genomförande:
Kontrollera identitet
Kontrollera att studenten finns på listan
Ge studenten bordsplacering
Utdelning av tentor
Insamling och kvittering av tentor
Räkna tentor, kontrollera att alla finns i bunten
Låsa in i kassaskåp
Tabell 2.1: Arbetsmoment [14]
2.3
Befintliga system
Det finns redan idag ett flertal tjänster som tillhandahåller möjligheten att
skapa, skriva och rätta digitala tentamina över internet. Av de tjänster som
vi hittade under vår forskning så var det ingen som hade stöd för alla de
7
olika frågetyper som kan förekomma på en tentamen. Det som ingen av
dessa tjänster tillhandahöll var att kunna kompilera och visa kompileringsfel på frågor där studentens svar var skrivet i programspråk. Det alternativ
för programmeringsspråk som de andra tjänsterna för att skapa tentamina
tillhandahöll var att skapa en textfråga där studenterna kan skriva in koden och sedan får läraren rätta denna för hand. Undantaget vi hittade var
Kattis 2.3.2 som används vid Kungliga Tekniska högskolan vid labbar och
koduppgifter. Kattis har dock inget stöd för att skapa en tentamen.
2.3.1
DigiExam
En av de tjänster som idag finns på marknaden är DigiExam. Den fungerar
som så att läraren skapar en tentamen på deras hemsida genom att skapa
ett antal frågor. Det finns tre olika sorters frågor att välja mellan och dessa
är textfråga, flervalsfråga med ett rätt alternativ och flervalsfråga med flera
rätta alternativ. I alla sorters frågor går det att lägga till bilder i frågan
samt dra in frågor från andra tentamina man sparat. När läraren är klar
med en tentamen så sparas den i DigiExams bibliotek och när man sedan vill
att studenterna ska kunna skriva tentamen så går läraren in i detta bibliotek
och väljer att göra tentamen tillgänglig för eleverna.
När studenten sedan ska skriva tentamen så loggar den in i DigiExams
egna applikation med bland annat examens-ID, student-ID och namn. Examen med motsvarande examens-ID laddas då in och studenten kan besvara
frågorna. På textfrågor får man skriva in sitt svar i en textruta och sedan
kan man välja att rita bilder och lägga till dessa till svaret. Om det är en
flervalsfråga får man kryssa i det/de alternativ som man tror är rätt. När
studenten svarat på alla frågor så lämnar den in tentamen.
Läraren kan sedan gå in på en avslutad tentamen och rätta den. Läraren
får då upp en fråga samt svar för en student i taget. Om det är en flervalsfråga
så rättas denna automatiskt och det markeras vad som är rätt och vad som
är fel. Det finns möjlighet för läraren att bläddra mellan de studenter som
8
svarat på tentamen samt de olika frågorna. När läraren rättar tentamen ges
det möjlighet att skriva i hur många poäng man vill ge studenten på frågan
och om man vill kan man också skriva in en kommentar till svaret. När alla
frågor för en student har rättas så får läraren skriva i vilket betyg som ska
ges på tentamen. [13] [26]
2.3.2
Kattis
Kattis är ett webbgränssnitt och ett program som testar programmeringskod
automatiskt. Kattis utvecklades vid institutionen för datavetenskap och kommunikation på Kungliga tekniska högskolan [24] för att studenterna snabbt
skulle kunna få reda på om koden de skrivit fungerade eller inte. Ett annat syfte med Kattis var att ge studenterna träning i att söka upp buggar i
koden. [19]
I Kattis finns det en lista med problem som man kan välja att lösa. Ett
exempel på ett problem som finns i Kattis går ut på att skriva ett program
som tar emot flera talpar. Dessa talpar används för att testa programmet
genom att jämföra programmets utdata med den förväntade utdatan för de
specifika talparen som indata. På så sätt kan Kattis kontrollera programmets
korrekthet. I detta exempel går uppgiften ut på att returnera absolutbeloppet av differensen av dessa tal. [22]
Den som löser uppgiften väljer ett av de språk som stöds i Kattis och
skriver sin kod för att lösa problemet i detta språk. Sedan så skickar man in
sin kod till Kattis som då kompilerar koden och exekverar den med ett antal
olika indata. Kattis ger sedan information om varför koden gjorde det som
förväntades eller inte. [20]
Den information som man får tillbaka av Kattis kan vara en av åtta olika
meddelanden. De åtta olika meddelanden som kan förekomma är:
• Accepted: Man har lyckats lösa problemet.
• Compile Error: Kattis lyckades inte kompilera koden.
9
• Run Time Error: Programmet kraschade under exekvering.
• Time Limit Exceeded: Programmet hann inte exekveras klart innan
problemets tidsgräns var nådd.
• Wrong Answer: Programmet exekverades korrekt men svaret var fel.
• Output Limit Exceeded: Programmet gjorde för mycket output och
stängdes därför av.
• Memory Limit Exceeded: Programmet har försökt allokera mer minne
än vad som tillåts för problemet.
• Judge Error: Det har uppstått en bugg eller felkonfigurering i Kattis.
[21]
2.3.3
Itslearning
Itslearning är en mycket använd kurshanteringstjänst. Förutom funktioner
för att hantera vanligt kursinnehåll finns det även möjlighet att skapa en
tentamen för studenterna. Eftersom Itslearning stöder plugins så finns det
flera olika typer av tentamen, men vi väljer här att fokusera på den officiella
modulen för digital tentamen som Itslearning skapat.
Modulen stöder anonymitet och har en personlig login som förhindrar att
studenterna kommunicerar med varandra under tentamen och övriga delar
av Itslearning är begränsade. Läraren kan dock definiera ”allowed aids”,
godtagbara hjälpmedel, på Itslearning som studenten kan nå även under
tentamen. Modulen har stöd för tio olika typer av frågor bl.a. ja/nej-frågor,
flervalsfrågor och textfrågor.
Frågorna på tentamen kan antingen automaträttas om de är flervalsfrågor
eller dylikt och annars så får de rättas av läraren. [17] [18]
10
2.4
Sammanfattning
I kapitel 2 har vi diskuterat syftet med vår studie och hur vi tror att den
kan bidra till en bättre studiemiljö för såväl lärare som studenter. Vi gav
en bakgrund över hur tentamen ser ut idag på Karlstad universitet och vad
ett digitalt tentamensystem skulle kunna tillföra. Vi har nämnt några av de
fördelar som detta system kan bidra till för både lärare och studenter. Vi har
gått igenom några av de tjänster som finns idag som till viss del har samma
funktionalitet eller som har samma syfte som vår studie.
11
Kapitel 3
Design
3.1
Introduktion
I detta kapitel ges en överblick av hela systemet och de designbeslut som
tagits. Systemets komponenter beskrivs ur ett designperspektiv och kapitlet syftar till att ge en bättre förståelse av systemets komponenter samt
dess relation till varandra. I bild 3.2 ser man hur komponenterna kommunicerar med varandra och hur systemet är uppbyggt. I avsnitt 3.2 beskrivs
lärarplattformen samt kommunikationslänken som tillsammans bildar det
som hädanefter går under namnet Webbserver. I avsnitt 3.3 ges en överblick
av Android-applikationen som är den komponent studenterna använder sig
av vid tentamen. I avsnitt 3.4 beskrivs kompileringsservern, den komponent
som sköter kompilering och exekvering av kod-uppgifter. I det avslutande
avsnittet 3.5 förklaras konstruktionen och designbesluten bakom databasen.
12
Fig. 3.1: Webbservern och Android-applikationens startsidor
13
Fig. 3.2: Systemöversikt
3.2
Webbserver
Webbservern är den komponent som sköter all kommunikation mellan de
olika delarna i systemet. En del av webbservern består av en kontrollpanel
för lärare i form av en hemsida. På hemsidan kan lärare skapa nya tentamina
och göra dem tillgängliga för studenterna samt se resultatet allt eftersom
studenterna lämnar in sina tentamina. Läraren kan granska varje individuell
tentamen samt sätta poäng på frågorna. När läraren har skapat sin tentamen
och vill publicera den så sparas all information om tentamen i databasen
där den då blir tillgängligt för övriga delar av systemet. När läraren vill
inspektera en tentamen, för att se resultaten från studenterna, söker läraren
på tentamens unika identifierare. Webbservern frågar då databasen efter
alla studenter som gjort tentamen och bygger upp en lista av studenter som
lämnat in tentamen. Läraren kan sedan göra en noggrannare inspektion av
varje individuell tentamen. Webbservern frågar då återigen databasen fast
denna gång efter den specifika studentens svar. Webbservern jämför sedan,
14
på de frågor det är möjligt, studentens resultat med facit och ger läraren en
överblick på hur studenten har klarat sig på tentamen. Läraren får sedan
själv sätta antalet poäng på varje individuell fråga. När läraren är klar räknar
webbservern ihop poängen och laddar upp den till databasen.
Den andra delen av webbservern fungerar som en kommunikationslänk
mellan de övriga komponenterna i systemet. Alla förfrågningar från de andra komponenterna går alltid först igenom webbservern. Webbservern kontrollerar så att all den information som krävs för ett specifikt anrop är skickat
som en eller flera parametrar. Webbservern konverterar sedan parametrarna
till korrekt format och vidarebefordrar sedan anropet till destinationen. När
destinationskomponenten har bearbetat anropet så skickar den sitt svar tillbaka till webbservern som i sin tur förmedlar det tillbaka till källkomponenten
för anropet.
3.3
Android-applikation
Android-applikationen är den del av systemet som kommer att användas
av studenterna under tentamen och den körs på en läsplatta. Studenterna
kommer att mata in sin anonymitetskod samt en unik identifierare för den
aktuella tentamen. Applikationen kommer att kontakta webbtjänsten som
hämtar ut tentamen från databasen och sedan returnerar denna till Androidapplikationen. För att veta vilken tentamen som ska hämtas skickar applikationen med den unika identifierare som studenten skrev in.
Under en tentamen kommer studenterna ha möjlighet att direkt kompilera kod genom att skicka denna till webbservern som skickar den vidare till
kompileringsservern. Kompileringsservern kommer att returnera ett meddelande om vad som fungerade eller inte fungerade enligt lärarens anvisningar.
Det kommer också att finnas möjlighet för studenten att rita bilder till de
olika uppgifterna. När studenten är klar med tentamen skickar applikationen upp svaren och bilderna till webbservern som skickar dem vidare till
15
databasen för lagring.
3.4
Kompileringsserver
Kompileringsservern, som även går under namnet KattisClone, är i grunden
utvecklad av Andreas Arvidsson vid Karlstads universitet och den baseras på
Kattis 2.3.2. Kompileringsservern har sedan modifierats och vidareutvecklats
för att det ska passa behoven för tentamensystemet.
Kompileringsservern är den del av systemet som hanterar kompilering
och exekvering av kod. Den tar emot ett objekt som bland annat innehåller
kod och försöker kompilera koden i det språk som angivits. Om kompileringen lyckas så exekveras koden och kompileringsservern kan sedan jämföra
utdatan från exekveringen med den utdata som läraren specificerat som korrekt utdata. Efter programmet har exekverat klart eller om kompileringen
misslyckades så returneras eventuella fel eller att programmet har lyckats
med kompilering och exekvering. Kompileringsservern ger olika mängd information beroende på vilka inställningar läraren angett för den nuvarande
frågan vid skapandet av tentamen.
3.5
Databas
Systemet använder sig av en MySQL databas för att lagra den data som
behöver lagras som till exempel de olika tentamina.
Valet av databassystem grundade sig i CAP-teoremet, även känt som
Brewer’s teorem, som är en avvägning mellan konsistens (consistency), tillgänglighet
(availability) och partition tolerans (partition tolerance) där man får prioritera två av dessa egenskaper högre än den tredje.
Konsistens betyder att varje förfrågan till databasen kommer att returnera rätt värde. Exempelvis så kommer det vid en läsning ifrån databasen
alltid vara det värde som senast skrevs till tupelen man försöker läsa från i
16
databasen som läses ut. I ett system som har konsistens så både börjar och
slutar en transaktion i ett konsistent tillstånd men det kan vara i ett icke
konsistent läge under utförandet.
Tillgänglighet betyder att varje förfrågan till slut kommer att få ett svar
oavsett hur lång tid det tar.
Partitionstolerans betyder att även om en del av systemet slutar fungera
så kommer de andra delarna av systemet fortfarande att fungera. [10] [11]
Då systemet har stort behov av att alla studenter ska kunna hämta tentamen och vara säkra på att det är rätt tentamen som har hämtats, så att
det inte finns risk för att någon student ska kunna bli utan tentamen eller få
fel tentamen, så prioriterades konsistens och tillgänglighet högst.
Fig. 3.3: Cap theorem [9]
Då konsistens och tillgänglighet prioriterades högst så ska det enligt CAPteoremet väljas en RDBMS(relational database management system). Av de
olika databaser som då finns att välja mellan så valde vi att använda en
17
MySQL databas på grund av att den inkluderar komponenter som till exempel InnoDB som är en databasmotor vars design följer ACID-modellen. ACID
står för atomär(atomicity), konsistens(consistency), isolering(isolation) och
hållbarhet(durability). [23] [16]
Med atomär menas det att en transaktion endera kommer att utföras helt
och hållet eller inte alls.
Med konsistens menas det att all den data som skrivs in i databasen
är giltig enligt de regler och restriktioner som finns för det fält man försöker
skriva till. Om en transaktion resulterar i felaktig data så kommer databasen
att gå tillbaka till sitt föregående läge innan transaktionen utfördes.
Med isolering menas det att även om två transaktioner utförs samtidigt
så måste resultatet av dessa transaktioner vara samma resultat som om de
hade utförts efter varandra.
Med hållbarhet menas det att efter att en transaktion är avslutad får de
ändringar som har skett aldrig försvinna oavsett vad som händer. [1]
3.6
Sammanfattning
I kapitel 3 diskuterades designen av systemet. Vi gav en överblick om hur
de olika delarna i system hänger ihop med varandra. Uppbyggnaden och
designbesluten av komponenterna motiverades och kommunikationen inom
systemet beskrevs ytligt.
18
Kapitel 4
Implementation
4.1
Introduktion
I detta kapitel ges en överblick över hur de olika komponenterna i systemet
är implementerade. I avsnitt 4.2 beskrivs webbserverns funktion samt implementation. En av webbserverns komponenter, lärarplattformen, beskrivs i
4.2.1. Där redovisas hur en lärare kan skapa en tentamen samt lärarplattformens
konstruktion och implementation. Den andra av webbserverns komponenter,
kommunikationslänken, beskrivs i 4.2.2. Kommunikationslänkens implementation beskrivs samt hur den kontrollerar och dirigerar data som skickas i
systemet. I avsnitt 4.3 beskrivs en del av de Android-specifika komponenterna som används i Android-applikationen och implementationen beskrivs
med hjälp av text samt kodexempel. I avsnitt 4.4 beskrivs implementationen
av kompileringsservern samt hur den kompilerar och exekverar kod. I avsnitt
4.5 ges en överblick över de tabeller som finns i databasen och de olika fälten
i dem beskrivs.
19
4.2
Webbserver
Webbservern består av två delar, lärarplattformen som sköter skapande samt
rättning av tentamina och en kommunikationslänk som sköter all kommunikation mellan de olika komponenterna i systemet.
4.2.1
Lärarplattformen
Lärarplattformen är utvecklad med cirka 59% HTML5, 39% JavaScript, 1%
PHP, 1% CSS och <1% SQL.
Stommen i plattformen består av HTML5 som bygger upp blocken av
hemsidan och ger den en grundläggande design. CSS sätter stil på blocken,
ger dem färg och hanterar till viss del positionering samt hemsidans dimensioner beroende på skärmstorlek.
När användaren vill skapa en ny tentamen måste användaren först fylla
i relevant information om tentamen till exempel titel, tentamens unika identifierare, examensansvarig och vilka hjälpmedel som är tillåtna. Dessa variabler sparas lokalt i användarens webbläsare tillsvidare. När detta är klart
får användaren möjlighet att lägga till frågor till sin tentamen. Alla olika
frågor har olika krav på indata och ser olika ut. För att snabbt kunna navigera mellan frågetyper och att slippa vänta på att sidan laddas om vid val eller
byte av frågor injiceras HTML kod dynamiskt med hjälp av JavaScript och
biblioteket jQuery. Detta ger sidan ett bättre flyt och användarupplevelsen
blir bättre än vid enbart statiska HTML sidor. När användaren valt en fråga
skapas alla indata-fält automatiskt för motsvarande fråga. Användaren kan
genom ett knapptryck till exempel lägga till extra alternativ till en flervalsfråga som även det injiceras med hjälp av JavaScript.
När användaren är klar med sin fråga trycker användaren på sparaknappen. Med hjälp av JavaScript och jQuery samlas då informationen om
frågan upp och konverteras till ett JSON-objekt. Nedan följer ett exempel
på hur en textfråga samlas upp och sparas i ett JSON-objektet.
20
var question = $("#question").val();
var questionID = examQuestions.Exam.length;
examQuestions.Exam.push({"ID":questionID,"Type":"text",
"Question":question});
Alla frågor och information om testet sparas i ett JSON-objekt och i
ett separat JSON-objekt sparas facit. Anledningen till att två olika objekt
används är framförallt för att inte exponera Android-applikationen för facit
och annan känslig information mer än nödvändigt.
Efter skapandet av en fråga visas alltid en förhandsgranskning av tentamens nuvarande frågor. Användaren har möjlighet att redigera, ta bort
befintliga frågor eller lägga till en ny fråga i slutet av tentamen. En tentamen kan innehålla alla olika typer av frågor. Det betyder att man kan variera
mellan flervalsfrågor, textfrågor och kodfrågor med mera.
När användaren är klar med sin tentamen och vill publicera den så trycker
användaren på spara knappen. JSON-objekten skickas genom en AJAXförfrågan från användarens dator till en PHP-fil på webbservern. Webbserven
kontrollerar så JSON-objekten är korrekta och att all obligatorisk information är ifylld. Om allt är som det ska så förbereder webbservern JSONobjekten för databasen genom att göra om dem till strängar med bibehållet
JSON-format. Strängarna laddas sedan upp till databasen med SQL.
4.2.2
Kommunikationslänken
Kommunikationslänken är helt och hållet skriven i PHP och SQL. Kommunikationslänken har i uppgift att förmedla information mellan de olika
komponenterna, konvertera mellan format och att validera den information
som skickas. Den konverterar bland annat mellan JSON-objekt och JSON
i sträng-format beroende på vilken applikation som kontaktar och vad den
förväntar sig i retur. Den första kontroll som sker är om klienten har bifogat alla de variabler som krävs för operationen som efterfrågas. Detta
21
kontrolleras genom en för PHP språkspecifik funktion, ”isset(...)”, som kontrollerar om ett angivet objekt finns eller ej.
if(isset($_POST[’examId’]) && isset($_POST[’student’])){...}
När en klient till exempel vill kontakta kompileringsservern som enbart tar
emot information via JSON så måste Kommunikationslänken konvertera all
information till JSON-format innan det förmedlas vidare.
$data = array("language" => $language, , "files" => $files, ... );
$data_string = json_encode($data);
$ch = curl_init(’http://ip-adress:8080/KattisClone/Api’);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_POSTFIELDS, $data_string);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
’Content-Type: application/json’,
’Content-Length: ’ . strlen($data_string))
);
$response = curl_exec($ch);
Kommunikationslänken sköter också all kontakt med databasen genom SQLförfrågningar som är specificerade på förhand. Vid SQL förfrågningar mot
databasen valideras indatan genom att specialtecken och sådant som är vanligt att använda sig av för att bifoga skadlig kod till rimlig mån oskadliggörs.
De andra komponenterna i systemet kontaktar kommunikationslänken via
olika PHP-filer beroende på vilken data de vill hämta ut från databasen.
22
4.3
Android-applikation
Android-applikationen är utvecklad i Android studio som är en integrerad
utvecklingsmiljö för Android-applikationsutveckling. Google, skaparna av
Android studio, tillkännagav Android studio på en av sina konferenser i maj
2013 men det dröjde drygt ett år innan de släppte en stabil version. De lovade under denna tid att Android studio skulle göra utvecklare snabbare och
mer produktiva och deras försäljningsargument var att det är den officiella
Android-utvecklingsmiljön. Den första stabila versionen av Android studio
släpptes den 8 december 2014 efter två års utveckling. [4] [6]
Användargränssnittet i Android är uppbyggt av vyer och vy-grupper.
Vyer är de objekt som ritar ut något på skärmen som användaren kan interagera med som till exempel knappar och textrutor. Vy-grupper är de
objekt som innehåller vyer eller andra vy-grupper för att definiera layouten
av gränssnittet. [7] Dessa vyer och vy-grupper kan definieras i en XML-fil
eller initieras under körning av programmet.
I Android-applikationen är stommen samt de statiska elementen definierade i XML-filen och de dynamiska elementen initieras under körning av programmet. Detta är gjort då det oftast är ganska svårt att skapa dynamiska
element i XML-filen.
Det finns flera olika subklasser till vy-grupper som alla tillhandahåller
ett unikt sätt att visa upp de olika element som finns i dem. De vanligaste
subklasserna är ”Linear layout” och ”Relative layout”. Element i en linear
layout placeras i vertikala eller horisontella rader medan man i en relativ
layout definierar elements placering relativt andra element som till exempel
att element A ligger till höger om element B. Storleken på vyer och vygrupper kan definieras som ett exakt värde eller så kan man välja att sätta
storleken till wrap content eller match parent. Wrap content sätter storleken
till den minsta möjliga som krävs för att de element som finns i vyn/vygruppen ska få plats medan match parent sätter storleken till samma storlek
23
som sin förälder.[2] Storleken på element i en linear layout kan också sättas
med hjälp av vikter som är ett attribut som talar om hur viktigt ett element är
i förhållande till de andra elementen. Ju viktigare ett element är desto större
plats i layouten kommer det att få. Exempelvis så har knappen som används
vid kompilering en högre vikt än knappen som används för att återställa
koden i vår Android-applikation vilket gör att den blir större och detta kan
ses i bild 5.5.[3] För att sätta vikten på knappen som återställer koden så
sätter vi dess layout-parametrar till linear layout-parametrar med vikt. Så
här ser skapandet av ”resetCodeButton” ut i kod.
Button resetCodeButton = new Button(this);
resetCodeButton.setText("Reset code");
resetCodeButton.setTextColor(getResources().getColor(R.color.white));
resetCodeButton.setBackgroundResource(R.drawable.button_shape);
resetCodeButton.setLayoutParams(new
LinearLayout.LayoutParams(0,LinearLayout.LayoutParams.WRAP_CONTENT,1.0f));
Bakgrunden på de olika elementen i applikationen som exempelvis knappar kan sättas till en färg eller så kan de sättas till en ”drawable resource”
som består av ”shapes”, former, för att skapa ett grafiskt element. Exempelvis så har ”resetCodeButton” bakgrundsresursen button shape som kan
ses i koden nedanför.
24
<?xml version="1.0" encoding="utf-8"?>
<layer-list
xmlns:Android="http://schemas.Android.com/apk/res/Android">
<item>
<shape Android:shape="rectangle">
<solid Android:color="@color/darkbrown" />
</shape>
</item>
<item Android:left="1dp">
<shape Android:shape="rectangle">
<solid Android:color="@color/darkgrey" />
</shape>
</item>
<item Android:top="40dp">
<shape Android:shape="rectangle">
<solid Android:color="@color/darkgrey" />
</shape>
</item>
<item Android:bottom="40dp">
<shape Android:shape="rectangle">
<solid Android:color="@color/darkgrey" />
</shape>
</item>
</layer-list>
I Android-applikationen representeras varje fråga som en egen layout och
när man går till en annan fråga så laddas en ny layout in i den del av fönstret
som är unik för varje fråga.
Android-applikationen skapar frågorna genom att kolla på det fält som
innehåller information om vilken typ av fråga det är i det JSON-objekt som
den hämtat ifrån databasen. Den kallar sedan på olika funktioner beroende
25
på detta värde och dessa funktioner lägger till de komponenter som den typ
av fråga består av som exempelvis radioknappar eller textrutor.
Frågan, som också finns i JSON-objektet, är uppbyggd av HTML element för att läraren ska kunna sätta stil såsom fetstil, färgad text eller
dylikt. För att konvertera HTML stilen till motsvarande stil i Android skapade vi ett java-bibliotek som gör just detta. Anledningen till att vi gjorde
detta själva var att det inte, till vår vetskap, finns något tredjeparts-bibliotek
som gör detta och standardbiblioteket för Android, ”Android.text.Html” ,
stöder långt ifrån alla de stilar som krävdes. För parsningen av HTML-koden
använde vi oss av jsoup-bibloteket. Jsoup konverterar HTML-strängen till
objekt som har egenskaper som ”barn”, ”text” och funktioner som ”getTagName” vilket förenklar hantering av taggar och dess barn. Vi planerade först
att göra parsningen själva via reguljära uttryck och hade en prototyp klar
men insåg snart att regex inte var rätt verktyg. Då regex använder sig av
reguljära yttryck och HTML inte är ett reguljärt språk, blir det omöjligt att
parsa HTML med regex. Det vi gör är att konvertera HTML-strängen till
objekt med jsoup och sedan välja ut de taggar och element vi ska hantera
ur objektet. Koden som följer är ett exempel på hur vi med hjälp av jsoup
väljer ut och hanterar alla heading taggar.
Document htmlDoc = Jsoup.parse(htmlSpan.toString());
Elements htmlElements = htmlDoc.select("h1,h2,h3,h4,h5,h6");
for(Element element : htmlElements){
replace(htmlSpan, element.toString(),
matchHeading(element.tagName(), element.html()));
}
Metoden replace byter ut en substräng av ”htmlSpan”. Substrängen är
definerad av ”element.toString()” och byts ut mot den formaterade sträng
som ”matchHeading”-metoden returnerar. ”MatchHeading” tar emot ett
elements tagg-namn och den text eller de element som finns innanför taggen
26
för att sedan konverterar dessa till en Android stil med liknande egenskaper
som motsvarande heading tagg hade i HTML. Liknande metoder finns för
flertalet typer av taggar och attribut. Hela källkoden kan ses på github.
Vid kommunikation med andra komponenter av projektet som exempelvis
vid hämtning av tentamen eller kompilering av kod så använder sig applikationen av http-post för att skicka information till den av kommunikationslänkens php-filer som kontaktar den komponent som applikation vill nå
och som sedan returnerar det som ska returneras till applikationen. Dessa
http-posts utförs i en klass som ärver klassen asynctask. Asynctask gör så
att de operationer som sker i klassen sker asynkront, det vill säga parallellt,
med det som utförs i andra delar av applikationen. Detta betyder att andra
delar av programmet inte behöver vänta på att de operationer som sker i
asynctask ska slutföras innan de fortsätter med sitt arbete. [5]
När studenten skriver en tentamen så har den möjlighet att kompilera och
köra koden den har skrivit på kodfrågor. För att göra detta måste Androidapplikationen först lägga ihop den kod som studenten skrivit med den kod
som läraren skrivit och definierat som icke synlig för studenterna. För att
göra detta så ersätter den en fördefinierad tag i den kod som läraren skrivit
med det som studenten har skrivit med hjälp av funktionen replaceTextInCode.
<string name="regexCodePattern"><Data><![CDATA[
<sc-begin>(.*)</sc-end> ]]> </Data></string>
...
private String replaceTextInCode(String hiddenCode, String myCode){
return hiddenCode.replaceAll(
getString(R.string.regexCodePattern),myCode);
}
Det denna funktion gör är att leta upp alla förekomster av regexCodePattern strängen i den kod som läraren definierat som icke synlig för studenten, vid skapandet av tentamen, och ersätta dem med den kod som stu27
denten har skrivit som svar på uppgiften. RegexCodePattern strängen är
ett reguljärt uttryck, vilket är en sträng som följer specifika syntax regler
och den strängen som applikationen försöker matcha ser ut så här: ”<scbegin>(.*)</sc-end>”.
Det finns också möjlighet för studenten att rita bilder till de olika uppgifterna
och detta görs med hjälp av canvas och bitmap. Canvas [12] är den grafiska
komponent studenten kommer att rita på och en bitmap är en matris av
punkter där varje punkt tilldelas en färg [8]. Det finns stöd för att rita fritt,
linjer samt fyrkanter och det går också att ändra färg såväl som tjocklek.
Studenten har också möjlighet att lägga till text i dessa bilder genom att
skriva en text och sedan välja var den ska placeras genom att dra och släppa
den i canvasen. När studenten vill rita en bild kopplar applikationen ihop
en canvas med en bitmap så att de pixlar som ritas på canvasen skrivs till
bitmappen. För att lagra dessa bilder i applikationen samt databasen görs
bitmappen om till en sträng och det är denna sträng som lagras.
När studenten är klar med tentamen och har valt att lämna in den
så sammanställer applikationen det som studenten skrivit och ritat till ett
JSON-objekt som den vidarebefordrar till kommunikationslänken som i sin
tur skickar det till databasen för lagring
4.4
Kompileringsserver
Kompileringsservern är skriven helt i Java och är plattformsoberoende. Den
drivs med hjälp av en apache server. När utvecklingen av kompileringsservern
för projektet började fanns det en bra grund att vidareutveckla ifrån. Kompileringsservern tog redan emot JSON-objekt med kod och kunde kompilera samt exekvera koden och returnera eventuella felmeddelanden. Det
fanns från början stöd för programspråken C och C++. För att få kompileringsservern att fungera i samspel med systemet så lade vi till stöd för
inställningar som skickas i samma JSON-objekt som koden. Vi implementer-
28
ade även stöd för Java. Koden för testfall modifierades från att använda filer
på hårddisk till att simulera filer i programmet genom att lagra programkoden i en sträng.
Kompileringsservern är inaktiv medan den väntar på en ’HttpServletRequest’ (Läs:[25]) från kommunikationslänken 4.2.2. Förfrågan ska innehålla
en JSON-sträng med information om språk, kod, förväntad utdata samt
inställningar för hur mycket information om testfallen och förväntade utdatan som ska exponeras till den som skickar förfrågan. Detta ger den som
skapar tentamen möjlighet att ange hur mycket hjälp studenterna ska få när
de ber programmet att kompilera deras kod. Det finns inställningar för att
avslöja allt om vad de fördefinierade testfallen förväntar sig för utdata, bara
avslöja att utdatan inte stämmer med testfallen eller inte avslöja något om
testfallen gick igenom eller inte.
Kompileringsservern tar emot data i form av en JSON-sträng via
void doPost(HttpServeltRequest,HttpServletResponse){ ... }
i klassen API. API är huvudklassen som dirigerar all data mellan de olika
klasserna stegvis. Det första som som sker med datan är att den genom
klassen InputData konverterar JSON-strängen till ett Java-objekt med hjälp
av Gson-biblioteket. Gson-biblioteket är ett bibliotek som används för att
konvertera data mellan Java-objekt och dess JSON motsvarighet och vise
versa. [15] Om konverteringen mellan JSON och Java-objektet lyckas så skapas filer på hårddisk med den koden som ska kompileras och med en filändelse
som motsvarar det språk som angetts. I programmet sparas filerna i en ArrayList<File>för fortsatt användning. Nästa steg är att försöka kompilera
filerna. En instans av en klass vid namnet Compile skapas och metoden
public ArrayList<File> run(File folder, ArrayList<File> files,
String language) { ...}
med filerna som skapades tidigare samt programspråk som in-parametrar
29
körs. I metoden, beroende på språk, konstrueras en lista av argument för
kompileringen. Listan skapas på formen <kompilator><alternativ><filer>.
För exempelvis programspråket C så konstrueras listan på följande sätt:
arguments.add("gcc");
arguments.add("-o" + outFile.get(0).getAbsolutePath());
arguments.add("--std=c99"); //Enable C99
arguments.add("-lm"); //Link math library
Det som är gemensamt för alla språk är att filerna läggs till i slutet av
argumentlistan
for (File file : files) {
arguments.add(file.getAbsolutePath());
}
När parameterlistan är färdig skickas hela listan till klassen Commands.
Commands är den klass som exekverar de kommandon som de andra klasserna
skickar. Commands hanterar både kompilering och exekvering av de skapade programmen. Compile returnerar sedan listan med de filer som ska
exekveras, filerna är antingen av filtypen .exe eller .Class, beroende på om
det är C, C++ eller Java. Om något fel sker vid kompileringen hämtas felet
ut och returneras och programmet avslutas. Om kompileringen gick bra så
skapas en instans av klassen execute, som har i uppgift att konstruera argumentlistan för att exekvera filerna som precis skapats. För C och C++ är
det så simpelt att dess enda argument är den exekverbara filens sökväg. För
Java så konstrueras argumentlistan på följande sätt
arguments.add("java");
arguments.add("-cp");
// Add the files location to class path
arguments.add(FilenameUtils.getFullPath(execFile.get(0).getAbsolutePath()));
30
for(File f : execFile)
{
arguments.add(FilenameUtils.removeExtension(f.getName()));
}
Argumenten konstrueras därmed enligt följande:
java -cp <file directory><file 1><file 2>... <file n>
Argumentlistan skickas sedan vidare Commands.execute som kör argumentlistan. Resultatet av exekveringen matchas sedan mot de förväntade
utdata som definierats när tentamen skapades och resultatet returneras och
programmet avslutas.
31
Fig. 4.1: Kompileringsserver klassdiagram
32
4.5
Databas
Databasen består av de två tabellerna ”exam” och ”taken exam”. I examtabellen så lagras alla tentamina samt de rätta svaren till dem och i taken exam
lagras det vad studenten har svarat och hur många poäng den fått. Det
mesta av den information som lagras är JSON-objekt omgjorda till JSONformaterade strängar
4.5.1
Exam
Tabellen exam 4.2 består av fyra stycken kolumner som är exam id, header,
exam och answer.
Kolumnen exam id är den kolumn som lagrar den unika identifieraren för
en tentamen och det är denna kolumn som används som primärnyckel i denna
tabell. Denna kolumn är av datatypen varchar med en längd på 20 på grund
av att en primärnyckel kräver en maximal längd och den unika identifierare
kan bestå av både siffror och bokstäver.
I kolumnen header så lagras all tentamensinformation för en tentamen
som till exempel titel och tillåtna hjälpmedel. Datatypen för denna kolumn
är text då formatet på det som lagras i den är ett JSON-objekt omgjort till
en JSON-formaterad sträng innehållande de olika attributen. Denna kolumn
tillåter inte null-värden då en tentamen måste innehålla tentamensinformation.
Exam kolumnen innehåller de olika frågorna på tentamen samt information om dessa. Denna kolumn har också datatypen text av samma anledning
som header kolumnen. I denna kolumn tillåter vi null-värden då man kan
vilja skapa tentamensinformationen och spara denna för att sedan vid ett
senare tillfälle kunna lägga till frågor.
Answer är den kolumn som lagrar de rätta svaren på frågorna för en
tentamen. Om det är en fråga som inte har något korrekt svar så lagras ett
null-värde som svar. Denna kolumn tillåter också null-värden då man inte
33
kan ha svar om man inte har frågor.
Fig. 4.2: Exam
4.5.2
Taken exam:
Tabellen taken exam 4.3 består av fem stycken kolumner som är exam id,
student id, answer, points och comments.
Exam id kolumnen innehåller samma värden och är av samma datatyp
som exam id kolumnen i exam tabellen. Tillsammans med student id kolumnen så bildar de primärnyckeln för denna tabell.
Kolumnen student id innehåller den unika identifieraren för en student.
Denna kolumn är också av datatypen varchar med en längd på 20 då det är
en del av primärnyckeln.
I kolumnen answer så lagras det vad studenten har svarat på de olika
frågorna. Formatet av informationen som lagras i detta fält är ett JSONobjekt omgjort till en JSON-formaterad sträng. Denna kolumn har datatypen
longtext då detta fält också lagrar de bilder som studenten har ritat till
frågorna. Anledningen till detta är att bilderna är bitmaps som är omgjorda
till en formaterad sträng som blir längre än vad datatypen text klarade.
Denna kolumn tillåter inte null-värden då en student måste lämna in svar på
en tentamen för att lagras, även om dessa svar är blanka.
Points kolumnen innehåller information om hur många poäng som läraren
har gett studenten på varje fråga vid rättningen. Datatypen för denna kol34
umn är satt till text då även denna kolumn innehåller ett JSON-objekt
omgjort till en JSON-formaterad sträng. Denna kolumn tillåter null-värden
då en tentamen inte måste vara rättad för att lagras.
Kolumnen comments innehåller de kommentarer som läraren har skrivit
till frågorna vid rättningen. Denna kolumn har datatypen text då den innehåller ett JSON-objekt omgjort till en JSON-formaterad sträng. Nullvärden tillåts för denna kolumn då man kan lagra en tenta utan att ha
kommentarer till den.
Fig. 4.3: Taken exam
4.6
Sammanfattning
I kapitel 4 beskrevs implementationen av systemet. Med hjälp av beskrivande
text, kodexempel och tabeller gavs en inblick i systemets komponenter samt
dess implementation.
35
Kapitel 5
Resultat
5.1
Introduktion
I detta kapitel kommer resultatet av projektet att presenteras. Presentationen ger en beskrivning av de olika verktyg både student och lärare får tillgång
till vid användning av detta system. I avsnitt 5.1 presenterar vi hur det ser ut
när läraren skapar en tentamen samt den funktionalitet som finns att tillgå.
I avsnitt 5.2 går vi igenom hur de olika vyerna i Android-applikationen ser
ut samt deras funktioner. I avsnitt 5.3 beskriver vi hur det kan se ut när
man rättar en tentamen samt vilka verktyg man har till förfogande.
36
5.2
Skapande av tentamen
Fig. 5.1: Skapande av tentamen
När läraren väljer att skapa en ny tentamen får läraren först fylla i relevant
information såsom tentamens-identifierare, ansvarig lärare och betygsgränser
med mera. När all obligatorisk information är ifylld kan läraren gå vidare
37
med att skapa tentamen
Fig. 5.2: Förhandsgranskning av tentamen
Läraren lägger till frågor i sin tentamen och ser en förhandsgranskning av
frågorna han eller hon skapar. Ramen runt förhandsgranskningen indikerar
om tentamen är sparad eller inte. Grön indikerar sparad och röd indikerar ej
sparad. Varje fråga har en kontrollknapp där läraren har möjlighet att flytta,
38
ta bort eller redigera frågan. Över förhandsgranskningen finns en ”drop-down
menu” för att välja vilken typ av fråga man vill lägga till i tentamen härnäst.
Fig. 5.3: Skapande av flervalsfråga
Vid skapandet av en uppgift får läraren lite olika alternativ beroende på
frågetyp. Vid till exempel flervalsfrågor så finns det möjlighet att lägga till
flera alternativ till en fråga. I bilden ovan ser vi ett exempel på hur det kan
39
se ut när läraren skapar en sådan fråga. När läraren är klar med frågan så
kan läraren, genom att trycka på spara knappen, lägga till frågan i tentamen.
Efter att läraren sparat frågan dyker automatiskt förhandsgranskningen upp
igen och läraren får alternativet att upprepa processen eller att spara tentamen.
Om läraren vill göra ändringar på en tentamen som tidigare skapats går
det också bra. Läraren får då navigera till vyn för att redigera tentamen, där
man får ange tentamens-identifierare. Tentamen hämtas då ut från databasen
och läraren kan ändra eller lägga till uppgifter till sin tentamen.
40
5.3
Tentamens-skrivande
Fig. 5.4: Startskräm i Android-applikationen
Bilden ovan är den första vy studenterna ser när de öppnar sin läsplatta för
att göra en tentamen. Det finns två fält man får fylla i där man ska ange
41
tentamens- samt sin personliga identifierare. Det är tänkt att studentens
identifierare tilldelas på ett liknande sätt som sker idag vid Karlstads universitet. Det vill säga att den personliga identifieraren automatiskt tilldelas
via internet när man anmäler sig till tentamen. Tentamens-identifieraren
bör finnas tillgänglig både på nätet men även tillgänglig i tentamenssalen
i form av en utskrift på tavla eller på annat sätt kommuniceras via tentamensvakterna. När studenten trycker på knappen ”Load exam” laddas
korresponderande tentamen in från en databas och studenten kan påbörja
sitt tentamensskrivande.
När tentamen laddats in så möts studenten av en informationssida där
den information läraren angav vid skapandet av tentamen visas. Bland informationen finns saker som ansvarig lärare, tillåtna hjälpmedel, betygsgränser
med mera. Längst ner i vyn finns ett navigeringsfält för att navigera mellan
frågor och informationssidan. Varje knapp på navigeringsfältet representerar
en fråga förutom nästa och föregående knapparna som kan användas för att
växla mellan frågor inkrementellt eller dekrementellt.
42
Fig. 5.5: Exempel på tentamenssvar i student-vyn
När studenten navigerar till en uppgift så visas frågan och man får även
olika interaktiva element beroende på frågetyp. Till exempel så generar en
flervalsfråga ett antal kryssrutor där studenten får välja de alternativ studenten anser vara korrekta. I den högra bilden ovan har studenten navigerat
43
till en fråga där studenten ska skriva programkod. Det finns möjlighet att
testa sin kod genom att använda sig av kompileringsknappen och resultatet
genereras i resultatrutan längst ner. I åtgärdsfältet högst upp i applikationen finns det möjlighet att byta till en ritvy där studenten kan rita bilder till
varje fråga för att förtydliga sitt svar. En indikator visar hur många bilder
som för nuvarande är kopplade till frågan. Längst till höger i åtgärdsfältet
finns det en ”Submit exam” knapp där studenten kan lämna in sin tentamen.
44
Fig. 5.6: Ritvyn i Android-applikationen
När studenten vill rita en bild som komplement till ett svar och navigerar
till ritvyn så laddas vyn som man kan se i bilden ovan. Navigationsfältet
längst ner byter syfte och man navigerar nu istället mellan de bilder man ritar
till aktuell fråga. Ett ritverktygsfält läggs till över ritytan, där studenten
kan välja mellan olika former, färger och andra verktyg för att skapa den
45
bild de vill. När man vill gå tillbaka till frågan så trycker man på knappen i
åtgärdsfältet som är till för att växla mellan bild och fråga.
5.4
Rättning av tentamen
Fig. 5.7: Tentamens resultat, ännu inte poängsatt
46
När läraren väljer att rätta en tentamen får läraren först ange tentamensidentifierare. Läraren får då upp en tabell med alla de studenter som har
lämnat in tentamen. Om studenten har fått poäng tilldelad på alla frågor
så kommer denna tabell också innehålla den totala poäng som studenten
blivit tilldelad. Om studenten däremot ännu inte fått poäng på alla frågor så
kommer det istället att stå att tentamen ännu inte är färdigrättad. Läraren
kan ladda ner resultaten som en csv fil som för varje student skapar en ny
rad innehållande studentens identifierare, poängen för varje fråga samt totalpoängen separerade med kommatecken. Detta gör att man enkelt kan
sammanställa statistik och övrig information om hur tentamen har gått.
Man kan även i tabellen på hemsidan välja en av studenternas inlämnade
tentamina och inspektera denna noggrannare. I denna inspektion får man se
de olika frågorna samt vad studenten har givit för svar.
47
Fig. 5.8: Rättning av programspråksfråga
48
Fig. 5.9: Rättning av tentamen och ritverktyg
När läraren rättar tentamen så får läraren fylla i studenternas poäng för
varje fråga. Poängen anges i en poängruta som finns under frågorna. Det
finns även möjlighet för läraren att lägga till en kommentar till frågan i
kommentarsfältet bredvid poängrutan. Läraren kan även, med hjälp av ett
ritverktyg, markera och understryka i studentens svar. Detta är gjort för att
ge läraren samma möjligheter som idag finns för tentamen på pappersark.
För de frågor där studenten har lagt till bilder finns det en knapp för att visa
och gömma dessa bilder.
49
Fig. 5.10: Tentamens resultat
5.5
Sammanfattning
I kapitel 5 presenterades resultatet av projektet. Istället för fokus på de
individuella komponenterna av systemet så ligger fokus på de synliga vyer
som presenteras för användarna. Kapitlet har för avsikt att ge en större
50
förståelse för systemet och hur det kan användas.
51
Kapitel 6
Slutsats
6.1
Sammanfattning
Fördelarna med ett digitalt system är många och kan bidra till en bättre
miljö för både studenter och lärare. Detta projektet visar på vad man kan
spara både i tid och kostnader men också bidra till en bättre arbetsmiljö,
då student och lärare inte behöver göra lika mycket förhand då mycket automatiserats. Det visar också att man med relativt små medel kan skapa
en fungerande prototyp som skulle gå att använda i praktiken. Vi redovisar
implementationen av hur ett sådant system skulle kunna vara uppbyggt och
vad som krävs för att skapa ett grundläggande tentamenssystem. Med hjälp
av kodexempel, bilder och beskrivande text redogör vi för hur vi har implementerat systemet och hur alla komponenter samverkar.
6.2
Projektevaluering
Vi satte från början ut att skapa en prototyp som skulle övertyga uppdragsgivarens kollegor och investerare om att fördelarna med ett digitalt tentamenssystem överväger kostnaden. Systemet blev närmare ett användbart
system än vad vi förväntade oss när vi började med projektet. Systemet går
52
idag att använda, det som dock saknas är koppling till övrig infrastruktur
såsom Ladok och Karlstad universitet samt vissa säkerhetsaspekter, då vi
inte har haft säkerhet som huvudfokus under detta projekt.
Mycket av det vi skapat har redan gjorts tidigare, det som gör detta
projekt unikt är framförallt stödet för programmeringsfrågor som ger lärare
möjlighet att specificera testfall och för studenter att testkompilera sin kod
under tentamens gång. Att få tillgång till att testkompilera och exekvera
kod ökar både realismen för tentamen samtidigt som det ger lärare möjlighet
att ställa mer avancerade frågor som är alldeles för långdragna att svara på
med penna och papper.
Något som varit ett viktigt mål under projektets gång har varit att de
positiva saker man kan göra med ett analogt system bör finnas även i det
digitala systemet. Vi har därför försökt uppfylla detta krav genom att till
exempel ge läraren möjlighet att rita i en students tentamen, för att markera
eller understryka delar i svaret samt ge studenter möjlighet att inkludera
förtydligande bilder till sina svar.
Sammantaget så visar projektet tydligt att ett digitalt system kan bidra
till minskade kostnader och tidsåtgång framförallt vid förvaring, transport
samt rättning av tentamina. Lärarna kan producera mer komplexa programmeringsfrågor och ett digital system bidrar till ökad realism för studenterna
då de har tillgång till de verktyg de vanligtvis har utanför tentamenssalen,
framför allt för frågor inom programmering och övrig datavetenskap.
6.3
Problem
Några av de problem vi stött på under projektets gång har varit väldigt
intressanta och lärorika. Ett av de större problemen vi stötte på var hur vi
skulle konvertera de stilelement som läraren sätter på texten vid skapandet av
frågorna samt de bilder läraren inkluderar till motsvarande format i Android.
Vår första tanke var ett av standard-biblioteken ”Android.text.Html” vilket
53
har möjlighet att konvertera HTML stil till ett textspann med bibehållen stil.
Problemet var bara att vi senare insåg att den stöder långt ifrån alla de stilar
vi behöver för projektet. Biblioteket stöder bland annat inte ”img” taggar
eller taggar med attributet ”style” som används mycket av den textredigerare
vi använder vid skapande av frågor. Vi började då leta efter ett tredjepartsbibliotek som stöder fler stilar men utan resultat. Vi stod nu inför ett val,
antingen minska antalet funktioner för läraren eller skriva en egen Htmlkonverterarare. Vi valde att skriva vår egen konverterare vilket man kan läsa
mer om i sektion 4.3
6.4
Vidareutveckling
I denna sektion beskriver vi potentiella möjligheter och förbättringar som
kan utforskas vid fortsatt utveckling av systemet.
6.4.1
Skapande och rättning av tentamen
En möjlig vidareutveckling som vi inte hade möjlighet att implementera, men
som efterfrågades av uppdragsgivaren, är automatisk betygsättning. Läraren
får då definiera gränser vid skapandet av tentamen och vid rättning sätter
programmet betyget för studenten, beroende på hur många poäng studenten
fick. Ytterligare en vidareutveckling är att för varje fråga så får läraren
specificera ett maximalt antal poäng och applikationen kan själv ge poäng
för frågorna upp till den maximala poängen. Detta bör kanske inte ske på
textfrågor men för flervalsfrågor och dylikt kan det fungera utmärkt.
Mer automatisk rättningshjälp av frågor har också potential för vidareutveckling. Ange nyckelord i textfrågor som applikationen automatiskt matchar är
ett exempel på en sådan möjlighet. Detta kan ge läraren en snabb uppfattning om hur relevant texten är och hur mycket av de nyckelord som bör
finnas i ett svar som texten innehåller.
54
Återanvändning av frågor är också något där vi ser stor möjlighet för
vidareutveckling. Det hjälper till att spara tid och är relativt lätt att implementera.
6.4.2
Android-applikation
I Android-applikationen finns det möjlighet för vidareutveckling framförallt
med ritverktyg och ritkomponenter. Fler verktyg för studenten och vanliga
modelleringsverktyg kan läggas till. Säkerhetskopiering under tentamen är
även det något som bör vidareutvecklas utifall batteriet på läsplattan tar
slut eller om applikationen kraschar.
6.4.3
Kodkompileringsserver
Kodkompileringsservern stödjer just nu tre språk,C, C++ och Java. Det
finns möjlighet att lägga till i princip vilket språk som helst utan större
modifikationer vilket gör detta till en utmärkt komponent att vidareutveckla.
6.4.4
Säkerhet
Säkerhet är något som behöver uppgraderas runt om hela projektet. Allt
ifrån säkra anslutningar till kryptering av data är av stor vikt om prototypen
ska implementeras i verkligheten.
55
Kapitel 7
Appendix
Källkod för alla olika komponenter i system går att finna på:
Webbserver https://github.com/carlmats/DVGC25
Android applikation https://github.com/zinksweden/AndroidApp
Html to Android https://github.com/carlmats/H2A
KattisClone https://github.com/carlmats/DVGC25-Kattis
56
Bibliography
[1] Atomicity, consistency, isolation, durability (acid).
http://www.
techopedia.com/definition/23949/atomicity-consistencyisolation-durability-acid. [Online; accessed 11-Apr-2015].
[2] Layouts in android. http://developer.android.com/guide/topics/
ui/declaring-layout.html. [Online; accessed 8-Apr-2015].
[3] Linear layout. http://developer.android.com/guide/topics/ui/
layout/linear.html. [Online; accessed 8-Apr-2015].
[4] Android studio overview. http://developer.android.com/tools/
studio/index.html. [Online; accessed 7-Apr-2015].
[5] Processes and threads.
http://developer.android.com/guide/
components/processes-and-threads.html. [Online; accessed 8-Apr2015].
[6] Google releases android studio 1.0. http://venturebeat.com/2014/
12/08/google-releases-android-studio-1-0-the-first-stableversion-of-its-ide/. [Online; accessed 7-Apr-2015].
[7] Ui overview.
http://developer.android.com/guide/topics/ui/
overview.html. [Online; accessed 7-Apr-2015].
[8] The innodb storage engine. http://en.wikipedia.org/wiki/Bitmap.
[Online; accessed 18-Maj-2015].
57
[9] Cap theorem. http://www.abramsimon.com/cap-theorem/. [Online;
accessed 10-Apr-2015].
[10] Perspectives on the cap theorem. http://dspace.mit.edu/handle/
1721.1/79112#files-area. [Online; accessed 10-Apr-2015].
[11] Cap theorem: Revisited. http://robertgreiner.com/2014/08/captheorem-revisited/. [Online; accessed 10-Apr-2015].
[12] Canvas and drawables.
http://developer.android.com/guide/
topics/graphics/2d-graphics.html. [Online; accessed 18-Maj-2015].
[13] Hur fungerar det. https://www.digiexam.se/sv/how-it-works. [Online; accessed 6-Mar-2015].
[14] S. Forsberg. Förstudierapport för elektronisk tentamen. Technical report, Karlstads universitet, 2014.
[15] Gson. https://code.google.com/p/google-gson/. [Online; accessed
6-Apr-2015].
[16] The innodb storage engine. http://dev.mysql.com/doc/refman/5.0/
en/innodb-storage-engine.html. [Online; accessed 11-Apr-2015].
[17] Introduction to tests. https://files.itslearning.com/help/en-gb/
content/learning%20tools/test/introduction.htm. [Online; accessed 11-Mar-2015].
[18] Test tool.
https://files.itslearning.com/help/whatsnew3_3/
flash/uk/new_test_tool_viewlet_swf.html. [Online; accessed 11Mar-2015].
[19] Om kattis. https://kattis.csc.kth.se/about. [Online; accessed 9Mar-2015].
58
[20] Kattis documentation. https://kth.kattis.com/help. [Online; accessed 9-Mar-2015].
[21] Possible judgements. https://kth.kattis.com/help/judgements#wa.
[Online; accessed 9-Mar-2015].
[22] A different problem. https://kth.kattis.com/problems/different.
[Online; accessed 9-Mar-2015].
[23] Mysql and the acid model. https://dev.mysql.com/doc/refman/5.
6/en/mysql-acid.html. [Online; accessed 11-Apr-2015].
[24] Projekt: Kattis. http://www.csc.kth.se/utbildning/kth/kurser/
DH2622/mdifk07/mdi-fk-grupp3-Kattis.pdf. [Online; accessed 9Mar-2015].
[25] Httpservletrequest. http://docs.oracle.com/javaee/6/api/javax/
servlet/http/HttpServletRequest.html. [Online; accessed 6-Apr2015].
[26] Digiexam - 5 easy steps away from a digital exam. https://www.
youtube.com/watch?v=WNYlpUeHme8. [Online; accessed 6-Mar-2015].
59