Den här sidan beskriver hur projektet bedöms. Läs igenom den innan du börjar! Många problem som leder till komplettering kan undvikas om man känner till kraven i förväg.
Sidan är lång, dels för att vi vill ge er så mycket information som möjligt om vad vi ser efter, dels för att en del av den är lärorik studiematerial i sig. Men vi börjar med en snabböversikt som svarar på de vanligaste frågorna.
Tabellen nedan sammanfattar de viktigaste kraven. Längre ned på sidan ges fullständiga förklaringar.
Observera: Reglerna gäller under årets inlämningstillfällen, och vid komplettering får du minst ett år till på dig att använda samma regler. Därefter kan nya regler gälla.
| Labbar | Betyg 3 | Betyg 4 (utöver 3) | Betyg 5 (utöver 4) |
|---|---|---|---|
| Labb 5 | — | Godkänt på del 1 ("Betyg 4"), individuellt | Godkänt på hela labb 5, individuellt |
| Projektprogrammering | Betyg 3 | Betyg 4 (utöver 3) | Betyg 5 (utöver 4) |
| Fungerande projekt | Projektet ska fungera bra; någon enstaka bugg kan accepteras även om den stör användningen | Inga buggar som lätt upptäcks vid testning och stör användningen märkbart | Samma |
| Omfattning | Motsvarande 3 hp (+3 vid pararbete) | Samma | Samma |
| OO-programmering & Java | OK användning av arv, polymorfism, inkapsling, klassbibliotek | Bra användning av arv, polymorfism, inkapsling, klassbibliotek | Hårdare bedömning |
| Kodstruktur & läsbarhet | Någorlunda välstrukturerad, lättläst, självförklarande kod; rimliga kommentarer för det mesta | Välstrukturerad, lättläst, självförklarande kod; rimliga kommentarer | Hårdare bedömning |
| Javadoc-kommentarer | — | Alla klasser och publika fält ska ha Javadoc | Samma som betyg 4 |
| Repetitiv kod | OK i mindre mängder | Bör undvikas; kan leda till komplettering | Hårdare bedömning |
| Död kod | Små mängder accepteras | Ska tas bort | Ska tas bort |
| Resurser (ClassLoader) | — | Krävs för programresurser (bilder, ljud, etc.) | Samma |
| Felhantering | Användarfel: ny chans till inmatning. Övriga fel: stacktrace + avsluta är OK | Alla fel ska hanteras rimligt på rätt plats; inga ignorerade undantag | Samma + logga alla fångade undantag |
| Loggning (java.util.logging) | — | — | Krävs: FileHandler + minst ~10 händelser + alla fångade undantag |
| Utseende | I princip ett icke-krav; tillräckligt för att man ska kunna använda programmet/spelet | Samma | Samma |
| Kodanalys | Betyg 3 | Betyg 4 (utöver 3) | Betyg 5 (utöver 4) |
| Kodanalysvarningar | SHOWSTOPPER = ej godkänt. SEVERE = stort problem. VARNING = Inte alltför många. Gäller varningar som är giltiga. | Samma, men många varningar får högre severity ("allvarsgrad") | Samma, men många varningar får ännu högre severity |
| Rapport | Betyg 3 | Betyg 4 (utöver 3) | Betyg 5 (utöver 4) |
| UML-diagram i rapport | ≥ 1 diagram | ≥ 2 diagram | ≥ 4 diagram |
| Rapport, övrigt | Mall används, implementationsavsnitt ger tydlig översikt (3–6 sidor) | Samma | Samma |
| Inlämning | Betyg 3 | Betyg 4 (utöver 3) | Betyg 5 (utöver 4) |
| Inlämningsprocedur | Följ hela inlämningsproceduren". Annars kan din inlämning återlämnas utan granskning. | ||
När du lämnar in ditt projekt granskas det i två omgångar: först av en handledare, sedan av examinatorn. Resultatet kan bli:
Det tar mycket tid att bedöma och kommentera ett projekt, så vi kan inte ge en fullständig förhandsbedömning. Vad vi kan ge är de tydliga kriterier och den kodanalys som beskrivs på den här sidan.
För betyg 3 på moment PRAx i Ladok krävs inte att man genomför någon del av labb 5.
Projektet ska fungera bra. För betyg 3 kan någon enstaka bugg accepteras, även om den stör användningen.
Projektet ska motsvara 3 hp, ungefär 80 timmar per person (6 hp / ~160 timmar vid pararbete). Omfattning handlar inte bara om radantal utan om komplexitet och variation.
Statistiskt sett har godkända projekt ofta minst 500 rader kod (exklusive tomrader och kommentarer). Vi bedömer inte på radantal — smart är bättre än långt — men om projektet ligger märkbart under detta är det en varningssignal.
Projektet ska demonstrera att du kan använda arv, polymorfism och inkapsling på ett genomtänkt sätt. Använd också Javas klassbibliotek på ett bra sätt, särskilt de delar som diskuteras på föreläsningarna eller täcks av kodanalysen.
Ta alla chanser att programmera objektorienterat. Det är 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. Men du behöver inte försöka tvinga in fler OO-finesser i ditt projekt bara för sakens skull; programmera på ett sätt som löser problemet, som åstadkommer att du får de finesser du vill ha.
Välstrukturerad, lättläst kod är inte en detalj, utan ofta den mest tidskrävande och viktigaste delen av programmeringsarbetet. Slutmålet är inte bara ett program som åstadkommer rätt saker, utan ett program som gör det på rätt sätt.
Sträva efter självförklarande kod: bra namn, rimligt stora metoder vars namn visar vad de gör, inga magiska konstanter. Kommentarer behövs i många fall. Fokusera då på att förklara varför du gör något, inte på att mekaniskt upprepa vad koden gör.
Javadoc-kommentarer är ett sätt att dokumentera koden på ett strukturerat sätt som kan generera HTML-dokumentation automatiskt. För betyg 3 krävs allmän läsbarhet men det finns inga specifika krav på just Javadoc.
Undvik onödiga upprepningar. Abstrahera, parameterisera och generalisera. Upprepa till exempel inte kodrader när en loop hade gjort jobbet enklare. Ge namn till deluttryck som används många gånger eller som är del av längre och mer komplicerade uttryck.
Kod som aldrig kan anropas eller nås ska tas bort. Kodanalysen pekar ut sådana ställen.
Om programmet läser in resursfiler som tillhör programmet (bilder, ljud, banor, inställningar m.m.) är det viktigt att dessa hanteras på ett sätt som fungerar oavsett var programmet är installerat.
ClassLoader för resursfiler. Vanlig filhantering accepteras.
ClassLoader.getSystemResource() ska användas för programresurser, inte vanlig filhantering. Det
gör att programmet fungerar oavsett var det är installerat och även om det är packat i en JAR-fil. Du ska
också testa detta genom att packa i en JAR-fil och köra därifrån, utanför din utvecklingsmiljö.
(Om du skriver till en fil behöver du inte använda resurser för den filen, inte heller för att läsa
den.)
Uppfångade fel får inte ignoreras. Det gäller både exceptions och andra felindikationer
(t.ex. att en metod returnerar null).
Loggning är ett sätt att spåra programmets körning och fånga upp fel utan att störa användaren. Detta krav gäller enbart för betyg 5.
FileHandler för att logga till fil.
Utseendet är i princip ett icke-krav för alla betygsnivåer. Det ska vara tillräckligt för att man ska kunna använda programmet eller spelet, men vi bedömer inte estetik.
Vår automatiska kodanalys skapar issues i ditt GitLab-projekt och ger omedelbar återkoppling. Ta varningarna på allvar. Vi ser ofta inlämningar med för många ignorerade varningar, och tvingas då ge komplettering.
| Nivå | Vad det innebär |
|---|---|
| SHOWSTOPPER | En ej åtgärdad (och ej korrekt motiverad) SHOWSTOPPER gör att du inte kan få betyget. Är det en showstopper för betyg 3 leder det normalt till komplettering. |
| SEVERE | Allvarligt problem. Kan möjligen vägas upp av hög kvalitet på annat håll, men riskera inte det — åtgärda det. |
| WARNING | Problem som bör åtgärdas. Några stycken brukar inte vara avgörande, men undvik att samla på dem. |
| WEAKWARNING | Mindre problem. Ett större antal kan märkas i bedömningen. |
| POLISH | Finputsning. Vi noterar dem men de påverkar normalt inte betyget. |
Varningarna visas också med sannolikhetsindikation: ALWAYS, ALMOST_ALWAYS, USUALLY eller SOMETIMES. Avfärda inte en varning direkt för att sannolikheten inte är maximal. Vi aktiverar bara varningar som tillräckligt ofta pekar på verkliga problem.
@SuppressWarnings eller //noinspection, men kommentaren med motivering
måste ändå finnas — det ingår i examinationen.)Disclaimer: Kodanalysen är ett verktyg som ger en ungefärlig förhandsvisning av bedömningen. Den kan inte bedöma allt, och den kan ge false positives. Den ersätter inte en handledares omdöme.
UML-diagram ska användas för att belysa specifika aspekter av implementationen, inte som ett "allt-i-ett"-klassdiagram över hela projektet. Tillvägagångssättet ska vara: när du beskriver något i texten och ett diagram skulle göra det lättare att förstå, lägg till ett diagram för just det. Klassdiagram som visar hierarkier är ett alternativ bland flera; komposition och interaktionsdiagram är andra.
| Betyg | Krav |
|---|---|
| 3 | Minst 1 UML-diagram |
| 4 | Minst 2 UML-diagram |
| 5 | Minst 4 UML-diagram |
UML-diagram kan skapas i IDEA Ultimate Edition. På universitetet startar du det genom att
avsluta IDEA (om det kör), köra module add prog/idea på kommandoraden och sedan
starta IDEA som vanligt. Gör det bara när du faktiskt ska arbeta med UML-diagram! Om för
många studenter alltid kör Ultimate Edition kan licenserna ta slut. Du kan också skaffa en
gratis studentlicens för att använda det hemma.
Inuti IDEA kan du börja med ett tomt diagram och manuellt lägga till klasser (tryck SPACE), eller börja med ett större diagram och ta bort det du inte vill ha (högerklick → "delete").
Man får gärna också använda andra editorer, t.ex. draw.io.
Rapporten skrivs i den mall vi tillhandahållit (projektplanen behålls som första del). Implementationsavsnittet ska ge en tydlig och begriplig översikt av hur programmet fungerar och är strukturerat, typiskt 3–6 sidor text. Det är en del av examinationen och delvis ersättning för en tenta. Frågan vi ställer oss är: Går det att förstå hur implementationen fungerar och varför ni valde att bygga den så?
Mallen ska användas och innehålla all begärd information, både projektplanen (även om den inte har lämnats in för förhandsbedömning) och slutdelen. Rapporten ingår i examinationen och bedöms som en del av helheten.
Det finns en separat sida med många specifika programmeringstips — en kortfattad lärobok fokuserad på just de problem vi ser oftast i inlämningar. Läs igenom den ordentligt. Många av de problem som leder till komplettering finns beskrivna där, med konkreta exempel och råd.