Projektet ges betyg 3, 4, 5 eller komplettering.

För att projektet ska få godkänt ska man givetvis följa instruktionerna på projektsidan. Projektet ska skrivas i Java 8, projektbeskrivning ska lämnas in före deadline, alla ska göra ungefär lika stor del av koden, inlämningsinstruktionerna ska följas, och så vidare.

För de högre betygen ställs högre kvalitativa krav inom dessa tre områden:

1. Kodkvalitet. Som vi har diskuterat tidigare är slutmålet inte bara att få ett program som åstadkommer rätt saker, utan att få ett program som gör på rätt sätt. Några exempel på detta är att koden ska vara:

   • Lättläst. Bra namngivning är ett krav, så att även den som inte är helt insatt i koden kan läsa det mesta utan att gå till dokumentationen. Lagom långa metoder är också bra. Struktur och modularitet (nästa punkt) är också viktigt för läsbarhet.

     Dokumentation ingår i läsbarhet. Dokumentationskrav, och balansen mellan dokumentation och namngivning, beskrivs i de allmänna kvalitetskriterierna. Ett av kraven är att varje klass har en beskrivande Javadoc-kommentar.

   • Välstrukturerad och modulär. Varje klass och metod ska till exempel ha ett eget tydligt ansvarsområde, så att man lätt hittar i koden. Om en metod gör många olika saker är det ofta bra att bryta ut delar till sina egna metoder, så som vi har diskuterat på en föreläsning. Om man vill ändra en specifik finess i koden är det också bra om man behöver ändra på så få ställen som möjligt, och så vidare.

   • Robust. 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. För betyg 5 får man definitivt inte helt enkelt skriva ut något fångat fel till skärmen och fortsätta, utan korrekt felhantering är ett måste.

   • Effektivt skriven. Till exempel kan man ofta bli av med upprepad kod genom att införa hjälpmetoder, abstrakta hjälpklasser, eller liknande.

   Se även de mer utförliga kvalitetskriterierna, och de allmänna kriterier för bra objektorientering som diskuterats på föreläsningarna.

2. Objektorientering och Java. Precis som en öppen tentafråga låter er "på fri hand" demonstrera vad ni kan inom ett område, är projektet till för att ni ska demonstrera att ni har lärt er objektorienterade och Java-relaterade begrepp och vet hur de ska användas.

   Om ett problem kan lösas på ett OO-sätt eller ett icke-OO-sätt ska ni alltså använda OO-lösningen, om den inte är uppenbart sämre. Exempel: Om ni kan lösa samma problem med subtypspolymorfism eller med en switch-sats med grenar för olika objekttyper, ska ni normalt använda subtypspolymorfism. Annars visas inte era nya kunskaper!

3. Omfattning motsvarande projekttiden på runt 100 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 brukar rent statistiskt ha minst 1000 rader kod (exklusive tomrader, kommentarer osv). Många av de "bästa" projekten från de senaste åren var flera gånger större än så.

     Detta betyder inte att vi bedömer storlek efter antal kodrader!. Vi tar också hänsyn till kodens komplexitet och variation. Men den kod som har uppfyllt dessa kriterier har oftast också blivit minst 1000 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, kan ge komplettering.

   • Vår rekommendation: Fokusera på kvalitet, funktionalitet och att utnyttja era 100(+100) timmar väl. Om ni funderar över projektets omfattning, diskutera med er labbhandledare.

För varje betygsnivå finns flera kvantitativa villkor. Flera av dessa har att göra med projektbeskrivningen, där ni t.ex. ska svara på hur ni har använt vissa objektorienterade finesser och hur ni har gjort designbeslut. Andra kriterier har med själva implementationen att göra. Vi beskriver dem kortfattat här och fortsätter sedan med mer detaljerade förklaringar.

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

Det är viktigt att projektet låter er visa en bredd i era kunskaper inom Java, objektorientering och övriga programmeringskunskaper som kursen omfattar. För att underlätta den bedömningen har vi tagit fram en lista över specifika "finesser" som kan ge "breddpoäng". Ni kan även ge egna förslag till examinatorn (i god tid innan den slutliga projektbeskrivningen lämnas in).

För att man ska få sådana poäng räcker det inte med att använda en funktionalitet på ett minimalt sätt, t.ex. att "implementera filhantering" genom att öppna en fil, skriva ut en sträng och stänga filen. Se istället varje punkt som en öppen tentafråga där vi ber er visa t.ex. hur filhantering i Java fungerar. Där vill ni så klart ge relativt omfattande exempel för att vara säkra på att koden demonstrerar era breda kunskaper, så ni kan få full poäng på frågan!

I den slutliga projektbeskrivningen kommer ni att skriva en lista på vilka "finesser" ni har använt. För denna punkt räcker det att ange vilken finess och var den används, utan vidare reflektioner.

• En egen enum-typ som givetvis ska användas på ett ställe där den passar in i koden.

• En egen exception-klass, som precis som de standardiserade feltyperna kan spara undan information om vad som gick fel. I detta fall vill vi att ni använder sådana egna klasser på alla ställen där det är rimligt. Tänk genom vilka feltyper man kan vilja fånga separat och skapa olika exceptionklasser för dessa olika feltyper.

• Generics (avancerat): Att skapa en egen klass som är "generic" (har typparametrar). Här är det så klart viktigt att man faktiskt drar nytta av generics och inte bara lägger på det "ovanpå". Omimplementationer av grundläggande generella datatyper som listor, mängder och mappningar som redan finns i Collections Framework räknas inte. Fråga examinatorn om du är osäker.

• Använd assertions så som vi har beskrivit dem under föreläsningarna för att fånga upp olika typer av programmeringsfel. Användning på 1-2 platser i koden räcker inte, men man behöver inte heller använda dem för att till exempel testa alla parametrar till alla metoder. Använd dem där det verkar rimligt och beskriv hur ni har tänkt.

• Grafiskt gränssnitt. De flesta projekt innehåller antagligen detta, men man kan också tänka sig projekt där kommandoradsprogram utvecklas. OBS: För att räknas här måste det grafiska gränssnittet vara konstruerat "manuellt". Använder man ett GUI-designverktyg demonstrerar man inte att man själv är bekant med klassbiblioteken.

• Tangentbordsstyrning. Se till att ha "mnemonics" (understrukna bokstäver) i alla menyer. Använd key bindings via InputMaps eller menyernas setAccelerator()-metod för att lägga in tangentbordskombinationer (shortcuts) för lämpliga kommandon, som Alt-F4 för att avsluta.

• Egen GUI-komponent, precis som i Tetris-spelet.

• Filhantering med t.ex. File{In/Out}putStream alternativt *Reader/*Writer. I ett spel kan man till exempel spara en highscorelista, ladda in highscorelistan igen vid nästa programstart, ta hand om situationen när ingen highscorefil existerar, rapportera eventuella fel i filhanteringen på ett bra sätt, och så vidare.

• "Resurshantering" där man använder "resources" för att hämta in till exempel grafik eller ljud som har installerats tillsammans med programmet du har utvecklats. (Se föreläsningsbilderna där vi diskuterar varför resources är användbart och hur det ger tillgång till programmets egna filer oavsett var det är installerat, även om alla filer till exempel är packade till ett enda JAR-arkiv.)

• Ljudhantering. För att få poäng räcker inte en enda "blipp", utan detta bör användas i projekt där man har användning av olika ljud vid olika tillfällen. Se till att läsa in ljuden på lämpligt sätt (med resurser) och att ta hand om fel som kan uppstå om ljudfilerna inte finns. Ljud som spelas ofta bör läsas som ljudklipp in en gång för alla snarare än att läsas från disk vid varje uppspelning.

• Textbehandling av mer avancerat slag än enkla meddelanden, t.ex. att läsa in och tolka innehållet i en konfigurationsfil (som inte är helt trivial utan har några olika parametrar som kan sättas), eller att i ett spel kunna läsa in banor eller annan information som lagrats i textformat i en fil och konvertera dem till "riktiga" interna format.

• Användning av Java:s XML-klasser för att t.ex. hantera konfigurationsfiler eller annan information som sparas och/eller läses in.

• Loggning av programhändelser och fel med hjälp av Javas loggningsfunktionalitet.

• Nätverkskommunikation (överkurs). Nätverkskommunikation ingår inte i kurskraven och kan vara komplicerat. Den som "på eget ansvar" vill välja att implementera nätverkskommunikation kan få breddpoäng för detta.

• Multitrådning (överkurs), där programmet explicit använder flera trådar för att t.ex. dela upp tunga beräkningar på flera processorer eller för att göra saker i bakgrunden under tiden huvudprogrammet fortsätter på ett annat spår. Den multitrådning man får automatiskt i ett Java-GUI (via händelsehanteringstråden) räknas inte. Det räcker inte heller att lägga ett anrop i en egen tråd där man egentligen lika gärna kunde ha struntat i extratråden, utan det ska finnas en bra anledning till multitrådning.

Designmönster kan också ge breddpoäng. Vi begränsar oss här till ett fåtal mönster som beskrivs under föreläsningarna och/eller är jämförelsevis enkla att förstå. För att ett mönster ska ge poäng ska det användas för att implementera funktionalitet där det mönstret faktiskt passar och är till hjälp! Ni behöver också själva implementera designmönstren i sin helhet. Om ni använder en Comparator som argument till Javas sorteringsmetoder räknas det inte som att ni har implementerat Strategy-mönstret, eftersom ni inte själva har skapat gränssnittet eller metoderna som använder sig av det.

Det kan vara möjligt att få poäng för vissa andra mönster än de i listan. Kontakta i så fall examinatorn i förväg och förklara vilket mönster ni vill implementera. Skicka också med en pekare till den beskrivning av mönstret som ni har läst. Designmönster beskrivs ibland felaktigt på nätet.

MVC och Observer ger inga poäng, delvis för att vi har använt dem tidigare.

• State, som har diskuterats på föreläsningarna.

• Strategy, som har diskuterats på föreläsningarna.

• Factory Method. Tänk på att detta inte är samma sak som en enkel fabrik / fabriksmetod, utan det måste t.ex. finnas ett gränssnitt för fabriken, och det måste finnas klasser som "tar emot" en fabrik som de använder för att skapa objekt (så man utifrån kan välja att skicka in olika typer av fabriker till den som använder fabriken).

Vi vill också examinera en djupare förståelse för de objektorienterade begrepp vi har infört i den här kursen. I koden syns slutresultatet – i projektbeskrivningen får ni visa hur ni kom fram till detta. För varje betygsnivå ska ni därför beskriva hur ni har använt ett visst antal olika typiska egenskaper hos just objektorienterade språk. Precis som en tentafråga är detta alltså en skriftlig uppgift där ni får ytterligare en möjlighet att demonstrera er förståelse av objektorientering och programmering utöver det som direkt syns i själva koden.

Icke-typiska egenskaper är t.ex. datatyper, enum-konstanter och serialisering av datastrukturer, som finns i olika former i många icke-OO-språk. Typiska egenskaper hos OO-språk inkluderar dessa (fråga gärna examinatorn om ni har egna förslag):

• Användandet av gränssnitt (interface) för att representera abstrakta datatyper som har flera konkreta implementationer.

• Abstrakta klasser för att specificera gemensam funktionalitet hos en uppsättning klasser.

• Implementationsärvning, där en klass ärver metodimplementationer och fält från en annan (och lägger till egen kod alternativt "modifierar" existerande metoder via overriding). Här menar vi ärvning från en konkret superklass, för att skilja det från punkten ovan.

• Sen/dynamisk bindning inom en typhierarki, för att anropa "rätt" implementation av en metod utan att känna till objektets verkliga typ.

• Konstruktorer för att initialisera objekt.

I projektbeskrivningen finns en numrerad lista där ni kan lägga till en punkt för varje egenskap ni vill diskutera. Där beskriver ni tydligt:

• Vilken egenskap det gäller.

• Exempel på hur ni använt den, och var. Ange exakta namn på klasser och metoder så att det lätt går att hitta exemplet/exemplen, och beskriv vad ni har åstadkommit genom att använda egenskapen (vilket "problem" ni ville lösa).

• Hur ni kunde ha löst detta (på ett rimligt sätt!) utan objektorientering, ifall ni hade använt ett språk där den aktuella egenskapen inte var tillgänglig.

• Hur lösningarna skiljer sig åt. Vad vinner (eller förlorar) ni på att använda använda den objektorienterade finessen istället för att lösa det på något annat sätt? Eller är lösningarna kanske likvärdiga, även om de ytligt ser olika ut? Här ska ni alltså jämföra med en någorlunda rimlig alternativ lösning, som man faktiskt kunde ha använt om man ville lösa samma "problem" i ett icke objektorienterat språk.

När man har flera någorlunda rimliga alternativ för hur programmet ska designas och struktureras, och väljer ett av alternativen, tar man ett designbeslut. För varje betygsnivå ska ni beskriva ett antal designbeslut ni har tagit. Anledningen är både att ni ska visa oss hur ni har tänkt (som en tentafråga) och att ni själva ska fundera och reflektera över era val.
Många studenter har kommenterat att de har lärt sig mycket på att tänka genom dessa beslut!

Dokumentera detta under projektets gång – annars glömmer man lätt!

Vad är INTE ett designbeslut? Att man väljer int istället för long för ett visst fält är snarare ett "kodningsbeslut" – vi är intresserade av design på en lite högre nivå. Sådant som ska göras enligt projektkraven är inte (gruppens) designbeslut, t.ex. att de flesta fält ska vara privata. Det behöver också finnas alternativa lösningar som är så rimliga att beslutet inte blir helt trivialt och uppenbart. Att man använder konstruktorer för att man i sitt projekt inte har någon som helst användning av factory-mönstret är ett alltför trivialt beslut. Att dela upp koden i flera klasser är också ett uppenbart beslut i ett projekt av denna storlek.

I projektbeskrivningen finns en numrerad lista där ni kan lägga till en punkt för varje beslut ni vill diskutera. Detta ska vara andra lösningar än de som räknades upp under "användning av objektorientering"! I listan beskriver ni tydligt:

• Vad ni ville åstadkomma.

• Hur ni gjorde detta. Namnge klasser och metoder som är inblandade.

• En rimlig alternativ lösning som ni kunde ha använt istället.

• Varför den lösning ni valde var bättre än alternativet. (I vissa fall kanske ni inser att den lösning ni valde till slut blev sämre än alternativet – beskriv då varför.)

Är ni osäkra får ni gärna fråga handledarna, som i första hand kommer att bedöma projektspecifikationerna.

För varje betygsnivå ska den slutliga projektbeskrivningen innehålla minst ett visst antal UML-diagram. Dessa kan t.ex. göras 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 (dvs, undvik dem om ni bara vill illustrera klasstrukturen).