Göm menyn

Projektbedömning

När du lämnar in ditt projekt kommer det att granskas i två omgångar, först av en handledare / assistent och sedan av examinatorn.

Syftet med projektbedömningen är delvis att examinera dina kunskaper, delvis att hjälpa dig lära dig vad du behöver veta för att skriva högkvalitativ kod. Kod som du kan vara stolta över, som du lättare kan utöka och ändra, som ni kan förstå ett år senare, och som andra kan förstå om de skulle ta över ditt projekt. Därför kan vi både ge kommentarer som ger komplettering vid nästa inlämningstillfälle och ge tips om förbättringsmöjligheter som kan vara bra att känna till och tänka på i framtiden.

Resultatet av bedömningen kan bli att:

  • Du uppnår ditt önskade betyg.
    I TDDD78 och TDDE30 ges betyg 3, 4 eller 5. I 729A85 ges betyg G eller VG.

  • Du uppnår just nu ett lägre betyg utifrån ditt nuvarande projekt. Då får du dina poäng, men i denna kurs har du också möjlighet att plussa (höja betyget) vid senare inlämningstillfälle genom att fortsätta arbeta med samma projekt. Detta gäller garanterat under årets inlämningsmöjligheter, som visas på deadlinesidan. När nästa kursomgång börjar kan du behöva följa nya regler!

  • Ditt projekt blir inte godkänt och behöver kompletteras vid senare inlämningstillfälle enligt deadlinesidan. Komplettering kan behövas även om det är uppenbart hur man skulle förbättra koden så att den blir godkänd – för det är genom att göra man lär sig mest, inte genom att förklara hur man kunde ha gjort. Under årets inlämningstillfällen kan du fortsätta komplettera enligt årets regler. När nästa kursomgång börjar kan du behöva följa nya regler!

Bedömningskriterier: Allmänt

Vilka kriterier är det som bedöms? Vi kan diskutera detta på flera abstraktionsnivåer.

  1. På den mest abstrakta nivån vill vi främst uppnå god objektorientering, bra användning av Java, och välskriven, välstrukturerad, lättläst och robust programkod.

  2. Det kan vara svårt att gå direkt från den nivån till att bedöma den övergripande kvaliteten på ett helt projekt. Därför kommer vi längre ner på den här sidan att diskutera ett större antal bedömningskriterier.

    • För vissa kriterier finns det tydliga skillnader på kravnivå för olika betygssteg. Dessa skillnader diskuteras i gröna "rutor" på denna sida.

    • Andra viktiga kriterier är svåra att mäta och kvantifiera. Vi kan till exempel inte ge ett strikt villkor för "hur läsbar" och "hur objektorienterad" koden ska vara för ett visst betyg, och vi kan inte ge en uttömmande beskrivning av alla aspekter som man kan tänkas vilja uppfylla. Här krävs istället en bedömning av handledaren och examinatorn, och ju högre betygsambition, desto högre krav ställs.

      I den bemärkelsen är alltså projektet som en tenta: Man kan aldrig veta exakt när man har lärt sig tillräckligt mycket för att få godkänt, eller när man har besvarat en fråga tillräckligt bra för att få full poäng. Man får helt enkelt jobba på till man tror man har klarat gränsen med rimlig marginal.

  3. För att hjälpa dig granska din egen kod kommer vi på en annan sida att ge många specifika, konkreta exempel på bra och mindre bra programmering. Detta inkluderar:

    • De viktigaste kriterierna, bland dem som går att konkretisera och exemplifiera.

    • De kriterier som projekten oftast bryter mot, enligt vår långa erfarenhet av projektgranskning.

    • Ett antal inspektionsvarningar som vi vill förklara närmare.

Det tar ett par timmar att bedöma och kommentera ett projekt, så det är omöjligt för oss att ge en fullständig bedömning i förväg. Men i mån av tid kan handledarna titta på projektet och ge tips, vilket knappast händer under en tenta. Utnyttja detta i god tid! Fråga gärna även andra kursdeltagare om de har några minuter för att ge förslag och kommentarer.

Bedömningskriterier: Programkod

Siffrorna nedan refererar till stycken i sidan med specifika, konkreta exempel.

1, 13. Undvik fel som kan upptäckas automatiskt

En hel del potentiella problem i programkod kan upptäckas automatiskt, genom algoritmer som analyserar koden och upptäcker specifika mönster. IDEA kan göra detta åt dig. Följ instruktionerna.

Oavsett betygsambition: Inspektera koden med korrekt profil och åtgärda varningar enligt instruktionerna. Annars kan du få omedelbar komplettering utan att handledaren går genom projektet. Att granska ett projekt med många inspektionsvarningar är slöseri med tid.

2, 3, 4, 5. Skriv förståelig kod

Läsbarhet är viktigt eftersom programmering ofta går ut på att utöka och ändra existerande kod. Tid som läggs ner på att göra kod lättläst och välstrukturerad, och att dokumentera, är alltså inte bortslösad utan sparas in med råge i senare utvecklingsfaser. Slutmålet är därför inte bara att skapa ett program som åstadkommer rätt saker, utan att skapa ett program som gör på rätt sätt. På exempelsidan diskuteras detta i flera olika sektioner:

  • Allmän kodstruktur och organisation, t.ex. indelning av kod i metoder, klasser och paket.

  • Kortfattad och koncis kod, som ger många exempel på hur man kan undvika upprepningar (identiska eller med variationer). Undvik Write Everything Twice – följ Don't Repeat Yourself!

  • Självförklarande kod, som handlar om att göra koden lättare att läsa genom att det är uppenbart vad den gör, istället för att man kommenterar vad den gör. Till exempel är bra namngivning, och att man inför namngivna begrepp, viktigt.

  • Dokumentation och kommentarer, som diskuterar hur man skriver de kommentarer som behövs även när många aspekter av koden är självförklarande.

Notera följande:

  • Betygsambition 3/G: Upprepad / repetitiv kod accepteras i små mängder. Alltför repetitiv och ineffektiv kod ger ofta komplettering, även när det inte gäller "exakt" upprepning. Gå genom all din kod och undersök om det finns något du tycker borde kunna uttryckas effektivare, kod där det känns som om du inte borde ha behövt skriva så mycket som du gjorde. Antagligen behövde du inte det!

  • Betygsambition 4/VG/5: Upprepad / repetitiv kod bedöms hårdare.

För kommentarer gäller följande krav:

  • Betygsambition 3/G: Projektbeskrivningen måste ge en bra översikt över programmet.

  • Betygsambition 4/VG/5: Varje klass ska kommenteras med en övergripande Javadoc-kommentar som beskriver klassen (syfte, användning, relation till andra klasser, ...). Kommentarerna ska vara tillräckligt informativa för att man ska kunna få en rimlig förståelse för klasserna helt utan att läsa någon programkod! Javadoc-formatet beskrivs i en kursbok du har valt, eller t.ex. i Oracles egen dokumentation. Självklart kan även andra kommentarer behövas.

    Dessutom ska alla eventuella publika fält kommenteras. (Sådana fält ska normalt undvikas.

6. Korrekt objektorientering

Programmera objektorienterat. Ta chansen att demonstrera att du har lärt dig begreppen som ingår i kursen och vet hur de ska användas. Detta är ju kursens mål! Om ett problem kan lösas på ett OO-sätt eller ett icke-OO-sätt ska du använda OO-lösningen, om den inte är uppenbart sämre.

  • Beroende på betygsambition kommer du i projektbeskrivningen att behöva beskriva hur du har använt ett visst antal objektorienterade egenskaper i ditt projekt.

Använd också objektorientering på korrekt sätt. Vissa aspekter av korrekt användning av objektorientering diskuteras under Korrekt objektorientering.

7. Korrekt användning av ärvning, polymorfism

Typhierarkier, ärvning och polymorfism är kraftfulla verktyg, men de ska inte användas till allt, och det finns ett antal fallgropar. Detta diskuteras under Ärvning, polymorfism med mera.

8. Korrekt inkapsling / synlighet

Vi har diskuterat hur man kan göra medlemmar privata eller "skyddade" (protected) för att till exempel gömma implementationsdetaljer. Under Inkapsling och synlighet påminner vi om några vanliga missar.

9. Korrekt användning av typer

Under Korrekt användning av typer påminner vi om några tänkbara misstag när der gäller användning av typer, bland annat vad gäller generics (generiska typer) och wrappertyper.

10. Felhantering och robusthet

Skriv robusta program. Hantera till exempel eventuella fel som kan uppstå på ett bra sätt, särskilt när det gäller problem som direkt kan triggas av en användare. Vanliga misstag och fallgropar visas under Felhantering och robusthet.

  • Betygsambition 3/G: Exceptions får inte bara ignoreras. Om man inte kan återhämta sig från en exception på korrekt sätt måste man ta hand om problemet. För betyg 3/G är det acceptabelt att hantera fel som inte kan "fixas" genom att skriva ut en enkel stacktrace och avsluta programmet – då undviker man i alla fall många farliga följdfel.

  • Betygsambition 4: Exceptions ska hanteras korrekt. Detta innebär bland annat att de ska fångas på rätt plats, att man inte får "fånga och ignorera / glömma bort" felen, att man ska tänka på följdfel, och att man vid behov ska ge rimliga felmeddelanden. Programmet ska inte avslutas om man istället kan återhämta sig och fortsätta.

  • Betygsambition VG/5: Exceptions som fångas ska loggas med hjälp av Javas loggningssystem (java.util.logging), tillsammans med rimliga felmeddelanden.

11. Korrekta designmönster

Att använda designmönster är inget krav, men om du gör det ska de användas korrekt. Exempel finns under Designmönster.

12. Körbara program

Projektet ska resultera i ett färdigt program som kan "levereras" för enkel installation och körning på någon annans dator – till exempel hos handledaren som ska testa inlämningen. Detta ställer ytterligare krav på programmet, som diskuteras under Körbara program.

  • Betygsambition 3/G: Filer får läsas in via vanlig filhantering.

  • 4, VG, 5: Javas stöd för resurser ska användas om du behöver läsa in filer (bilder, ljud, banor, inställningar osv.) som tillhör och "levereras med" programmet. På det sättet undviker vi att behöva ange var filerna finns i en specifik installation, och filerna kan hämtas även om hela programmet råkar vara packat i en JAR-fil (liknande ZIP-fil). Om du även skriver till en fil behöver du inte använda resurser för den filen, eftersom du i så fall ändå måste veta var filen är placerad.

Omfattning

Omfattningen ska motsvara projekttiden på runt 80 timmar/person. Omfattningen innebär inte bara "kodvolym" utan beror mycket på komplexitet, variation, och så vidare. Detta kriterium är av naturen mycket svårt att specificera närmare. Vad vi kan säga i förväg är:

  • Vi kan så klart inte godkänna ett projekt som ser ut att motsvara 25 timmars arbete – men hög kvalitet och bra användning av OO kan ändå till en viss del väga upp en mindre omfattning.

  • Projekt som är tillräckligt omfattande för 3/G brukar rent statistiskt ha minst 800 rader kod (exklusive tomrader, kommentarer osv). Många projekt från de senaste åren var flera gånger större.

    Detta betyder inte att vi bedömer omfattning efter antal kodrader!. Vi tar också hänsyn till komplexitet och variation. Men den kod som har uppfyllt dessa kriterier har oftast också blivit minst 800 rader lång.

  • Smart är bättre än långt. En smart och effektiv lösning är oftast bättre än en lång. Ineffektiv kod, t.ex. upprepningar av nästan identisk kod, har ofta lett till komplettering.

  • Vår rekommendation: Fokusera på kvalitet, funktionalitet och att utnyttja era 80(+80) timmar väl. Om du funderar över projektets omfattning, diskutera med en erfaren handledare i god tid.

Bedömningskriterier: Projektbeskrivning

Den slutliga projektbeskrivningen ska använda den mall vi tillhandahåller och ska så klart innehålla all den information som vi har begärt genom instruktionerna i mallen.

Projektbeskrivningen innehåller flera avsnitt som ska testa din förståelse av olika aspekter hos objektorienterad programmering. Hur mycket du behöver ta upp i varje avsnitt beror på det betyg du siktar på. Detaljerade förklaringar av vad du ska beskriva finns i mallen!

Krav Betyg 3/G Betyg 4 Betyg VG Betyg 5

Visa djupare förståelse för objektorientering genom att förklara hur du har använt ett antal olika typiska egenskaper hos just OO-språk, och hur man hade kunnat göra i språk utan dessa egenskaper.

2 st 3 st 3 st 4 st

Visa insikt i programdesign, hur man tänker när man strukturerar sina program, genom att dokumentera ett visst antal designbeslut. I koden syns ju bara slutresultatet – i beskrivningen får du en chans att visa mer om processen bakom besluten.

2 beslut 4 beslut 6 beslut 8 beslut

Visa förståelse för hur UML-diagram kan användas genom att inkludera ett visst antal diagram i förklaringarna av projektets struktur. Diagrammen kan t.ex. skapas i IDEA.

Varje diagram ska illustrera en specifik "intressant" aspekt av projektstrukturen och åtföljas av en beskrivning enligt instruktionerna i mallen. Metoder och fält ska bara finnas med i diagrammen om de är relevanta och diskuteras i texten (undvik dem om du bara vill illustrera klasstrukturen).

1 diagram 2 diagram 3 diagram 4 diagram

Ge oss tillräckligt med information! Se detta som tentafrågor där du försöker ge tillräckligt med information för att verkligen visa upp breda och djupa kunskaper.

För att minska risken för komplettering får du gärna lämna in ett eller två extra "svar" i varje avsnitt. Siktar du på femma kan du t.ex. beskriva 9-10 designbeslut istället för 8, så att du har en liten marginal om något av dem inte skulle bli "godkänt".

Bedömningskriterier: Inlämning

Vid inlämning ska du följa alla inlämningsinstruktioner. Annars kan din inlämning återlämnas utan granskning.


Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2018-03-28