Utveckling, intervention och utvärdering

4.3 ADR Andra iteration Val av analysverktyg

4.3.2 Utveckling, intervention och utvärdering

Val av analysverktyg

Under utvärdering i föregående iteration togs beslutet tillsammans med problemägaren att bortprioritera egenutvecklad programkod till förmån att nyttja befintliga Open Source analysverktyg. Genom att utforska vilka aktuella analysverktyg som fanns till förfogande för Javaprogrammering valdes tre verktyg ut för att ingå i projektet. Samtliga verktyg är väl etablerade inom Javautveckling. Verktygen valdes ut efter förmågan att generera förbättringsförslag på studenters lösningar samt matchades mot de krav som tidigare fastställdes i kravspecifikationen.

Analysverktyg Checkstyle

Checkstyle var det första utvecklingsverktyget som valdes för att kunna observera hur studenten efterlever specificerad kodstil. Verktyget kontrollerar automatiskt Javakod och verifierar namngivningskonvention, användning av hakparenteser, “white space”formatering, användning av import med många fler kodstilsegenskaper. Checkstyle är användbart för att kontrollera att koden är skriven efter riktlinjer. Programmet innehåller möjlighet att själv konfigurera, ändra regler eller tillämpa kodkonventioner inom Java från exempelvis Sun och Google.

AlaMutka (2005) nämner i sin artikel att verktyget Checkstyle kan användas för att kontrollera studentens kodstil, hon har dock inte kunnat hitta någon artikel som använder verktyget i utbildningsmiljö. Saikkonen, Malmi och Korhonen (2001) nämner att ett tillägg för att bedöma kodstil skulle vara ett användbart hjälpmedel, men är inget som dem själva har implementerat. Figur 1 Checkstyle rapport :compileJava :processResources UP‐TO‐DATE :classes :checkstyleMain [ant:checkstyle] /home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:3:5: warning: '{' should be on the previous line. [ant:checkstyle] /home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:4: warning: 'method def' child have incorrect indentation level 9, expected level should be 8. [ant:checkstyle] /home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:8:5: warning: '{' should be on the previous line. [ant:checkstyle] /home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:13:5: warning: '{' should be on the previous line.

[ant:checkstyle] /home/olof/exjobb/Calculator/src/main/java/MyCalculator.java:17:42: warning: WhitespaceAround: '{' is not preceded with whitespace. BUILD SUCCESSFUL Total time: 1.498 secs

I figuren visas ett exempel på Checkstyle i användning. Verktyget körs i kommandoprompten där feedback skrivs ut i egenskap av kodvarningar innehållandes vilken rad fel finns och vad den koden bör ersättas med.

Analysverktyget PMD

Checkstyles användningsområde är begränsat och riktar sig mot att bedöma kodstil och räcker därför inte för att uppfylla problemägarens krav. Med den anledning kompletteras artefakten av analysverktyget PMD för att kunna kontrollera mer komplicerade regler såsom programmets design, död kod, överansträngd kod, optimerbar kod och onödiga kodduplikationer. PMD genererar feedback genom rapporter i XML eller HTMLformat. Figur 2 PMD rapport olof@olof‐VirtualBox:~/exjobb/Calculator$ gradle pmdMain :pmdMain 2 PMD rule violations were found. See the report at: file:///home/olof/exjobb/Calculator/build/reports/pmd/main.html BUILD SUCCESSFUL Total time: 1.495 secs Analysverktyget FindBugs

FindBugs är ett verktyg som används för att hitta buggar. FindBugs klassificerar buggar i kategorier beroende på allvarlighetsgrad på exempelvis dålig praxis, korrekthet, prestanda samt efter kod som har invecklad konstruktion. Till skillnad från Checkstyle och PMD analyseras Java bytecode. Därmed kan andra typer av buggar hittas än vad verktyget PMD gör, för den skull kompletterar verktygen varandra. Figur 3 Findbugs rapport olof@olof‐VirtualBox:~/exjobb/Calculator$ gradle check :compileJava UP‐TO‐DATE :processResources UP‐TO‐DATE

FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':findbugsMain'. > FindBugs rule violations were found. See the report at: file:///home/olof/exjobb/Calculator/build/reports/findbugs/main. html * Try: Run with ‐‐stacktrace option to get the stack trace. Run with ‐‐info or ‐‐debug option to get more log output. BUILD FAILED Total time: 3.327 secs Testdriven utveckling

Utöver att verifiera och analysera användarnas källkod var ett prioriterat funktionalitetskrav att kunna kontrollera om studentens svar är korrekt. Att använda sig av enhetstest för att kontrollera studentens output är ett användbart sätt.

Figur 4 Testklass för MyCalculator

import static org . junit . Assert .*;

import java . io . FileNotFoundException;

import java . io . IOException;

import org . junit . Ignore;

import org . junit . Test;

public class MyCalculatorTest {

@Test

public void testAdd (){

MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 20 , calc . add ( 10 , 10 ));

}

@Test

public void testSubtract (){

MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 0 , calc . subtract ( 10 , 10 ));

}

@Test

public void testMultiply (){

MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 369 , calc . multiply ( 123 , 3 ));

}

@Test

public void testDivide () {

MyCalculator calc = new MyCalculator (); // MyCalculator is tested assertEquals ( 41 , calc . divide ( 123 , 3 ));

}

Under iterationen konstruerades tester för övningsuppgifter. Källkoden ovan är testklassen för MyCalculator som innehåller 4 stycken test där addition, subtraktion, multiplikation samt division testas. För samtliga metoder skickas två inparametrar in som ska använda under sin specifika metod och returnera ett värde.

Figur 5 Lösningsklassen MyCalculator

public class MyCalculator {

public int add ( int num1 , int num2 ) {

return num1 + num2; }

public int subtract ( int num1 , int num2 ) {

return num1 ‐ num2; }

public int multiply ( int num1 , int num2 ) {

return num1 * num2; }

public int divide ( int num1 , int num2 ) {

return num1 / num2; }

}

Ovan visas ett exempel på hur tänkta slutanvändare av systemet har konstruerat ett lösningsförslag med metodnamn som överensstämmer mot testklassen. Detta test skall sedan passera de tidigare konstruerade testerna.

Figur 6 Enhetstest exekveras

Här visas hur enhetstestet för lösningsklassen MyCalculator körs. Skärmdumpen visar hur de fyra testmetoderna; addition, subtraktion, division samt multiplikation kontrolleras. Varje test passeras, vilket indikeras av den gröna texten “PASSED” till höger om testmetodens namn.

Tabell 8 Statiska analysverktyg för Java

Verktyg Licens Webbplats

Checkstyle GNU LGPL V2.1 hϤp://checkstyle.sourceforge.net PMD BSD‐licens hϤp://pmd.github.io

FindBugs GNU LGPL hϤp://ﬁndbugs.sourceforge.net

För att täcka upp de analyserande kraven i kravspecifikationen, bortsett från de tidigare bortprioriterade egenskaperna, användes tre analysverktyg. I nedanstående tabell matchas verktygen mot de krav som hanteras.

Tabell 9 Kravmatchning

Analyserande krav Checkstyle PMD Findbugs TDD 1.1 ‐ Indentering av kod x

1.2 ‐ NamndeklaraϤoner x x

1.4 ‐ Användning av hakparentes ^x ^x 2.0 ‐ Kontrollera räϤ svar x 3.0 ‐ Begränsa antal kodrader x 5.0 ‐ Ge feedback x x x x 7.0 ‐ OpϤmeringsförslag (prestanda) ^x ^x 7.1 ‐ Leta eϤer död kod x 8.0 ‐ IdenϤﬁera kodduplicering x Val av buildverktyg För att på ett automatiserat sätt kunna inkludera både kompilering av programkod,

enhetstest och exekvering av analysverktyg tillämpades ett buildverktyg vid namn

Gradle. Genom att konstruera en buildkonfiguration där analysverktygen definieras att

användas och regeluppsättningar konfigureras behöver inte användarna själva utföra

någon installation eller installera analysverktyg. Detta hanteras av buildverktyget. Tabell 10 Val av verktyg Motiveringar till val av buildverktyg Erfarenhet Kännedom om verktyget fanns sedan tidigare Anpassningsbarhet Verktyget är enkelt att konfigurera Användarvänlighet Enkelt för slutanvändare att använda Tillgänglighet Finns för Windows, Linux och Mac OS

4.3.3 Reflektion

Kraven som noteras från kravspecifikationen kunde täckas upp genom att tillämpa

analysverktyg tillsammans med enhetstest. Vidare kunde analysprocessen effektiviseras genom att nyttja buildverktyg där allt är konfigurerat på förhand och

sköts automatiskt vilket uppfyller det icke funktionella kraven Användare ska inte

behöva utföra konfiguration och kravet Systemet skall lämna feedback till student omgående .

För nästa iteration måste formatering över feedback ses över. I regelverken för

analysverktygen Checkstyle och PMD måste regler definieras bättre. Vidare måste

feedbacken som visas för slutanvändare vara mer enhetlig och samstämmig. Tabell 11 Fasens tillämpade designprinciper Preliminära designprinciper Källa Vara överskådlig När studenten testar sin lösning bör varningar

presenteras direkt istället för att bli hänvisade till en

htmlrapport. Användare ska uppmärksammas av

varningarna direkt för att omgående börja utreda hur

felaktigheter ska lösas Identifierad i projekt Skapa god

struktur Att arbeta med ett test i taget för att tillämpa ett

sekventiellt arbetssätt Beck (2011) Ge omgående feedback Feedback skall ges omgående när lösningen är som

mest aktuell Konceptet Automatise rad bedömning Ge feedback efter försök Feedback bör ges till användare efter att ett

lösningsförslag har utförts Shute (2007)

4.4 ADR Tredje iteration

Innehållet i den tredje iteration fokuserar främst på att förbättra strukturen för

resultatet som visas i samband med att användarens övningsuppgift kontrolleras.

Vidare behövs flera regler justeras, främst gällande kodstil, men även anpassa regler

till nivå för introduktionskurs i programmering före ITartefakten testas av

slutanvändare.

4.4.1 Problemformulering

Under tredje iterationen förflyttades problemet till detaljnivå och blev samtidigt

nedbrutet till mindre beståndsdelar. Under tidigare iteration har det reflekterats över att feedback som genererades av

verktygen inte var enhetlig. En fråga som uppstod var hur feedback skulle kunna

genereras enhetligt för att användaren inte ska behöva klicka sig fram för att läsa flera

och hur ADRteamet gå tillväga gällande anpassning av regler för att hålla en lämplig

nivå i förhållande till en introduktionskurs i programmering.

4.4.2 Utveckling, intervention och utvärdering

Indentering Tidigare problem med indentering löstes genom att ändra konfigurationsfilen för

analysverktyget CheckStyle. Genom att godta indentering som fyra stycken blanksteg

samt lägga till detta värde för tabbredd under modulen TreeWalker klarar

analysverktyget att använda både blanksteg och tabbtecken vid indentering. Sekventiell testning För att inte alla test för en klass ska exekveras samtidigt sattes ‘@Ignore’ annotation in

i testklassen framför alla metodtest utom det inledande, vilket innebär att dessa tester

kommer att bli temporärt inaktiverade och inte exekveras av när buildverktyget kör

igenom testfilen. Med denna tillämpning kan studenten arbeta med ett test i taget och

successivt fortsätta med nästa test efter att föregående har godkänts genom att ta bort

ignoreannotationen metod för metod. Enhetlig feedback Eftersom en kommandoprompt redan används för att exekvera kodanalysen genom

buildverktyget, bör ett rimligt tillvägagångssätt, på en prototypnivå, vara att få

feedbacken sammanfogad i prompten. Efter att ha utforskat möjligheterna hittades ett

pluginet vid namn gradlequalityplugin. Med pluginet var det möjligt att dels använda

samtliga valda analysverktyg och få dessa printade direkt i prompten istället för att generera tre olika rapporter. Figur 7 Enhetlig feedback 4 Checkstyle rule violations were found in 1 files [Whitespace | EmptyLineSeparator] JamnaTa.(JamnaTal.java:12) 'METHOD_DEF' should be separated from previous statement. http://checkstyle.sourceforge.net/config_whitespace.html#EmptyLineSeparator [Blocks | NeedBraces] JamnaTa.(JamnaTal.java:14) 'if' construct must use '{}'s. http://checkstyle.sourceforge.net/config_blocks.html#NeedBraces [Indentation | Indentation] JamnaTa.(JamnaTal.java:15) 'if' child have incorrect indentation level 9, expected level should be 12. http://checkstyle.sourceforge.net/config_indentation.html#Indentation [Indentation | Indentation] JamnaTa.(JamnaTal.java:17) 'method def' child have incorrect indentation level 9, expected level should be 8. http://checkstyle.sourceforge.net/config_indentation.html#Indentation

1 (0 / 1 / 0) FindBugs violations were found in 1 files [Dodgy code | UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD] JamnaTal(JamnaTal.java:null) [priority 2] >> Unused public or protected field: JamnaTal.neverUsed This field is never used. The field is public or protected, so perhaps it is intended to be used with classes not seen as part of the analysis. If not, consider removing it from the class. Findbugs HTML report: file:///home/olof/exjobb/jamnaTal/build/reports/findbugs/main.html :jamnaTal:pmdMain UP‐TO‐DATE 2 PMD rule violations were found in 1 files [Design | SimplifyBooleanReturns] JamnaTa.(JamnaTal.java:14) Avoid unnecessary if..then..else statements when returning booleans https://pmd.github.io/pmd‐5.5.4/pmd‐java/rules/java/design.html#SimplifyBooleanRet urns [Braces | IfStmtsMustUseBraces] JamnaTa.(JamnaTal.java:14) Avoid using if statements without curly braces https://pmd.github.io/pmd‐5.5.4/pmd‐java/rules/java/braces.html#IfStmtsMustUseBrac es Utvärdering

Vid möte med problemägaren demonstrerades ITartefakten. Flertalet av de ställda

kraven på artefakten var uppfyllda och accepterades. Applikationen demonstrerades för testgruppen lärare för att visa krav som var

uppfyllda. Under demonstrationen löstes övningsuppgifterna och därefter kördes

buildverktyget för att generera feedback från analysverktygen. Testgruppen uttryckte

att den feedback som genereras beror helt på slutanvändarens programmeringsvana

och att detta inte är lämpligt när feedback ska undersökas om den värdefull. Istället

förespråkades en färdiglöst övningsuppgift med flertalet fördefinierade felaktigheter

för att faktiskt kunna identifiera om levererad feedback är användbar i sitt

sammanhang. Först då går det att testa om studenten kan tyda feedback, använda den

till att förbättra sin lösning samt tycker att feedback är motiverande och användbar.

4.4.3 Reflektion

Genom att få samtlig feedback från analysverktygen direkt i kommandoprompten gick

det fortare att arbeta med feedbacken än att läsa igenom tre stycken genererade

rapporter. För att kunna testa applikationen om feedbacken verkligen är användbar uttryckte

lärarna viktig information om hur testuppgifter bör utformas. Detta är användbart till utvärderingen med studenter för att kunna validera applikationen i sitt sammanhang.

Tabell 12 Fasens tillämpade designprinciper Preliminära designprinciper Källa Presentera feedback enhetligt Feedback bör vara enhetlig för att reducera distraktionen hos slutanvändare Identifierad i projektet Använd färdigkonstruerade övningsuppgifter En färdigkonstruerad övningsuppgift innehållandes felaktigheter bör användas vid utvärdering för att skapa validitet Identifierad i projektet

4.5 ADR Fjärde iteration

I den fjärde iterationen ligger fokus på att konstruera en färdiglöst övningsuppgift som

innehåller ett antal fördefinierade felaktigheter som slutanvändare, i form av

studenter, kommer att testa under utvärdering i iterationen.

4.5.1 Problemformulering

Efter den tredje iterationens utvärdering centraliserades problemformuleringen mot en

omkonstruktion av övningsuppgift. För att kunna utföra en konsekvent utvärdering

med hög repeterbarhet måste applikationen generera densamma feedback vid varje

utvärdering. Därför behöver ett antal fördefinierade felaktigheter eller varningar

genereras. I samråd med problemägare bör även dessa varningar vara i linje med

innehåll och kunskap för organisationens kurser i Java. Slutligen måste en

intervjuguide tas fram för att användas i kvalitativa intervjuer med studenterna under

utvärdering av artefakten. Problemet formulerades: ● Hur skall en lösning för en övningsuppgift konstrueras med ett antal

felaktigheter för att kunna testas på slutanvändare?

4.5.2 Utveckling, intervention och utvärdering

En färdiglöst övningsuppgift togs fram där totalt elva stycken felaktigheter

utformades. Uppgiften gick ut på att kontrollera om antalet 1: or var större än antalet

0: or, i en inparameter bestående av en array med heltal, och i sådana fall returnera

värdet ‘TRUE’. Vidare var de elva felaktigheterna uppdelade till fem Checkstylevarningar, 4 PMDvarningar samt två stycken FindBugsvarningar.

Figur 8 Färdig övningsuppgift med felaktigheter

(1)

public class Arrays {

public final int one = 1; (2) public final static int zero = 0; (3) (4) public int wasteVariable; (5)

public boolean compare01 ( int [] nums ) { (6) int count1 = 0;

int count0 = 0;

for ( int i = 0 ; i < nums . length ; i ++)

{ (7)

if ( nums [ i ] == one) (8) count1 ++;

if ( nums [ i ] == zero) (9) count0 ++;

} (10)

if ( count1 > count0 ) { (11) return true; } return false; } } Felförklaring (1) Javadockommentar saknas, författare saknas (Kodkommentering, Checkstyle), (2) Variabelvärdet ändras aldrig, fältet borde vara definierat ‘static’. (Optimering,

FindBugs)

(3) ‘public final static’ är i fel ordning, bör vara public static final. (Kodstil, Checkstyle)

(4) Variabel som är final och static bör namngiven i versaler. ‘zero’ bör vara ‘ZERO’. (Namnkonvention, PMD) (5) Variabeln används aldrig. (Tvivelaktig kod, FindBugs) (6) Felaktig indentering (Kodstil, Checkstyle) (7) Hakparentes på fel rad (Kodstil, Checkstyle) (8) Ifsats bör inte användas utan hakparentes (Kodstil, PMD) (9) Ifsats bör inte användas utan hakparentes (Kodstil, PMD) (10) Felaktig indentering (Kodstil, checkstyle) (11) Onödig ifsats vid användning av booleska uttryck. (Design, PMD)

Tabell 13 Varningar matchas mot krav Analyserande krav Varning (#) 1.1 ‐ Indentering av kod 6, 10 1.2 ‐ NamndeklaraϤon 3, 4 1.3 ‐ Kommentering av kod 1 1.4 ‐ Användning av hakparentes ^{7, 8, 9} 7.0 ‐ OpϤmeringsförslag (prestanda) ^2, 11 7.1 ‐ Leta eϤer död kod 5

För att arbeta mer sekventiellt och med en nedbruten arbetsuppgift i taget tillämpades

Kanbanmetoden. En kanbantavla användes där alla arbetsuppgifter bröts ner till

mindre beståndsdelar och blev till kort (liknande noteit lapp) som sedan sorterades in

i kategorier beroende på var i processen kortet befann sig (kvar att göra, utförs nu,

avklarat). Det underlättade arbetet med att exempelvis veta vilka delproblem som var

avklarade, vad som var kvar att göra, vilket krav som skulle matchas mot vilken

varning med fler. Efter att lösningen var färdigställd utformades en intervjuguide (se bilaga

intervjuguide) som användes vid utvärdering med slutanvändare. För att vara

konsekvent användes samma typ av frågor för varje felaktighet oberoende av

analysverktyg, detta för att kunna komma fram till slutsatser om något eller några

verktyg genererar användbar feedback enligt studenterna. Utvärdering av applikation med slutanvändare Vid test av applikationen fick studenten den färdiga lösningen presenterad med

information om att den innehöll ett antal felaktigheter. Vidare berättades att lösningens

problem kommer att presenteras genom feedback som genereras av tre stycken

analysverktyg när kommandot ‘gradle check’ körs i kommandoprompten. I samband

med analyskontroll kommer även lösningens svar att verifieras genom enhetstest. Den

enda interaktionen med buildverktyget är när kommandot ‘gradle check’ körs. Totalt testades applikation av fyra stycken studenter, två med mer erfarenhet och två

med mindre erfarenhet av programmering. De med mer erfarenhet hade utöver

under utvärderingen på distans användes fjärrskrivbord, för att erhålla likvärdiga

förutsättningar som lokal utvärdering. Trots deltagarnas skillnader i programmeringserfarenhet identifierades flertalet

liknande upplevelser och uppfattningar över vissa typer av fel. Flest liknande

uppfattning om feedback indikerades för verktyget Checkstyle. Exempelvis vid första

varningen (1) där samtliga studenter tyckte att det var tydligt att det saknades en

kommentar. Vidare var de flesta studenterna samstämmiga om att det borde finnas mer

information om hur en kommentar av typen Javadoc skall se ut. Vidare uttryckte

studenterna likvärdigt för varning (3), deltagarna förstod att ordningen för

åtkomstmodifierare var felaktig, men menade att detta borde förtydligas med vilken

ordning som är den korrekta. Gällande verktyget PMD var studenter eniga om att exempellösningar som PMD

genererade i HTML var bra och uttryckliga, exempel fel #11. Dock uttryckte

studenterna att detta bör presenteras för användaren. Den feedback verktyget

genererade i kommandoprompten ansågs inte detta att vara tillräcklig för en nybörjare

inom programmering, utan här behövs tydligare och mer utförlig förklaring, mer likt

den i HTMLexemplet. Sammanfattningsvis observerades att feedback verkligen bör vara enhetlig och

uttryckas tydligt för att skapa medvetenhet om hur målet ska kunna uppnås. Länkar

användes inte i den utsträckning som de borde. När länken (för PMD) visades

uttryckte sig alla studenter att det var bra med ett konkret exempel på hur lösningen

kunde förbättras, men länken användes inte, utan studenterna skulle hellre vilja få

exemplet presenterat för sig direkt.

4.5.3 Reflektion

Vid utvärderingen med slutanvändare uppkom designprincipen att feedback måste vara

anpassad efter erfarenhet. Vid utvärderingen visade sig att en del av den feedback som

verktygen presenterade inte var tillräckligt förklarande till studenter utan tidigare

erfarenhet av programmering. Respondenterna uttryckte även under utvärderingen hur viktigt det är med att feedback

presenteras för en ska visa ett konkret förbättringsförslag på en lösning, något som är enhetligt med teori för formativ feedback.

Tabell 14 Preliminära designprinciper iteration 4 Preliminära designprinciper Källa Vara förklarande Feedback om förbättringsförslag bör kunna exemplifieras Shute (2007) Anpassa feedback Feedback måste anpassas efter erfarenhet Koncept för feedback

In document Formativ feedback i programmering med tillämpning av statisk kodanalys (Page 23-36)

Utveckling, intervention och utvärdering

4.3 ADR ­ Andra iteration ­ Val av analysverktyg

4.3.2 Utveckling, intervention och utvärdering

4.3.3 Reflektion

4.4 ADR ­ Tredje iteration

4.4.1 Problemformulering

4.4.2 Utveckling, intervention och utvärdering

4.4.3 Reflektion

4.5 ADR ­ Fjärde iteration

4.5.1 Problemformulering

4.5.2 Utveckling, intervention och utvärdering

4.5.3 Reflektion

4.3 ADR Andra iteration Val av analysverktyg

4.4 ADR Tredje iteration

4.5 ADR Fjärde iteration