Sök på Nada    Kontakt  Webböversikt  


KTH

KTH Nada
ingår i
Skolan för datavetenskap och kommunikation

   
 

   
   
   
   
   
   
   
   
   
   
  arrow rigth
   
   
   
   
   
   
   
   
   

    
    
    
KTH / Nada / Utbildning / Teknologer / 2D1312

J-del

Kursens tredje moment, LAB3, är en större, individuell programmeringsuppgift i Java; en "J-uppgift". J-delen redovisas i tre steg under kursens andra period. Uppgifterna är tänkta att vara något så när svåra och tidskrävande, räkna med ca 80 timmar.

Specifikation

Innan programmet skrivs ska en datorskriven specifikation lämnas in. Syftet med specifikationen är att du ska tänka igenom problemet innan du försöker lösa det. Specifikationen ska vara skriven i en .java-fil, vara kompilerbar och lämnas in via webben. En handledare kommer att kommentera den och ge den betyget godkänd/underkänd. Vid återlämningen ska du ta med dig en minnesbild över programmet. Blir du underkänd på själva specen eller minnesbilden måste du dokumentera ditt färdiga program med javadoc.

Granskning

Innan det färdiga programmet kan redovisas för en handledare ska det testas (granskas) av en student. Studenten får du välja själv, men för din egen skull bör det vara någon ovän, eller kritisk person. Vid testen ska teststudenten kritiskt granska ditt program, testköra det och föra ett besiktningsprotokoll. Denna granskning är ett obligatoriskt moment. Varje kursdeltagare måste granska en uppgift. Alla uppgifter som ska redovisas för handledare måste granskas först. Om du inte hittar något program att granska så måste du istället dokumentera ditt program med javadoc. Syftet med granskningen är att du genom att kritiskt granska en annans program ska få en ökad förståelse för hur man ska (och inte ska) programmera. Erfarenhetsmässigt ökar samtidigt chansen att bli godkänd vid redovisningen med minst 50%.
Tips! Välj granskare först när du är klar att redovisa, och välj då någon som också är klar med sitt program, så att ni kan granska varandra.

Slutredovisning

Du väljer (normalt via webben) en tid för slutredovisning. Specifikationen med uppdaterad minnesbild, besiktningsprotokollet och granskaren ska medföras till slutredovisningen. Granskare som inte medföljer till slutredovisningen har ingen chans att försvara sin granskning och riskerar därmed att bli underkända om handledaren finner granskningen undermålig.

Det finns en lista på J-uppgifterna med länkar till lydelserna för att du ska kunna skumma och bestämma dig för en uppgift. På bokningslistan kan du välja en uppgift.

J-uppgifterna är av olika omfång vilket kräver olika mycket tid, men tidsåtgången är framförallt beroende av dina kunskaper när du börjar med J-uppgiften.

Som ett komplement till de "inbyggda" finesserna i Java så finns ytterligare Javafiler för J-uppgiften. Utnyttja gärna dessa, men tänk på att i enlighet med hederskodexen ALLTID ange varifrån koden kommer när det inte är din egen.

Efter kursens slut kan J-delen endast redovisas i omtentaperioder. Eftersom datorsystemen byts eller uppgraderas årligen så bör du vara medveten om att tiden du har på dig att redovisa din J-del är begränsad. Väntar du mer än ett år från kursstart med att redovisa kan lydelsen till din J-uppgift behöva bytas ut. Du måste då ta kontakt med kursledaren. Vi reserverar oss för att byten av datorsystem kan medföra att vissa eller samtliga J-uppgifter inte går att utföra i framtiden. Du kan alltså bara vara säker på att det går att redovisa din J-del fram till nästa kursstart.

Krav på J-uppgiftslösningen

Utöver kraven på funktionalitet som finns i uppgiftslydelsen gäller detta alltid:

Programmet ska vara användarvänligt och presentera sig vid programstart. Tydliga instruktioner ska ges på skärmen. Det ska vara lätt att förstå vad programmet skriver ut. Det är tillåtet att anta att indatafiler är felfria om inte annat anges i uppgiftslydelsen. Ingen felkoll behöver göras för att upptäcka om indatafiler verkligen existerar.

Programmet ska vara kommenterat upptill med författare, datum och ev. revisionsdatum. Överkommentera inte programmet i övrigt. Tänk på att det är kvalitet och inte kvantitet på kommentarer som räknas.

Programmet ska vara vettigt uppdelat i klasser och metoder, och metoder ska inte vara alltför långa (max en skärmsida). Det ska vara lätt att i efterhand gå in och förstå och ändra i programmet. Robust, flexibelt och lättläst är nyckelord.

Varje klass, instansvariabel och metod ska vara försedd med kommentarer. Ange vad klassen och variabeln representerar och vad metoden gör. För metoder bör man också ange vad indata (parametrar) och utdata (retur-värde) betyder. Det ska räcka att läsa kommentar och metodhuvud för att förstå hur en metod ska användas.

Namn på klasser, variabler och metoder ska vara vettiga. Alla deklarerade namn ska vara på samma språk, liksom alla kommentarer (engelska namn och svenska kommentarer är OK). Koden skall vara snyggt formaterad.

Nästan identiska kodstycken ska inte upprepas. Gör i stället generella klasser och metoder. Inför inte i onödan begränsningar. Inför konstanter för sådant som man kan tänkas vilja ändra framöver (om man skulle vilja arbeta vidare med din lösning) och för tal som inte ska ändras och går att beskriva med namn.



 
Sidansvarig: Vahid Mosavat <vahid@nada.kth.se>
Uppdaterad: 2005-09-09