Syftet med projektuppgiften är:

• Att ni ska designa och implementera ett eget OO-program från grunden.

• Att ni ska använda, och demonstrera hur ni använder, de OO-tekniker ni har lärt er utan att vara bundna av en fördefinierad uppgift eller ett kodskelett.

Projektet motsvarar ca 100 timmars arbete per person. Ni måste därför arbeta mycket på egen hand, utanför schemalagd tid. Annars är det stor risk att projektet inte motsvarar kursens poäng och att ni behöver komplettera.

Rapportera eventuella oklarheter eller problem direkt till examinatorn!

Det första steget i projektet är att förstå vilka krav som gäller för samtliga projekt och vilka kriterier som ni måste uppfylla för vissa betyg. Detta kan påverka hur ni ska bygga upp ert projekt. Läs därför bedömningssidan.

Innan ni börjar behöver ni själva välja vilket projekt ni vill utföra. En projektbeskrivning måste sedan skrivas och lämnas in till labbhandledaren, helst innan projektstart (det går bra att skriva på svenska). Syftet är:

1. Att ni ska tänka genom implementationen i förväg. Många studenter anser att man har tjänat mycket på detta steg.

2. Att er handledare ska kunna ge feedback om det är större problem med den valda inriktningen. (Mindre detaljer är svåra att kommentera eftersom mycket beror på era förkunskaper och exakt hur ni går tillväga.)

Vid slutinlämningen ska även en uppdaterad version av projektbeskrivningen lämnas in, med ytterligare information adderad. I båda fallen går det bra att skriva på svenska.

Det är bättre, både ur betygssynpunkt och för inlärningen, att ha ett projekt med något mindre omfattning men högre kvalitet än att ha ett större antal features som tyvärr inte riktigt fungerar.

Så är det även i "verkligheten", och i många projekt sker därför en feature freeze en tid innan en ny version faktiskt görs tillgänglig. Man slutar alltså lägga till nya finesser och spenderar tid enbart på att fixa problem och "städa upp".

Detta är extremt viktigt och ska göras även i detta projekt!

Ni kommer att ha cirka 10 minuter på er att demonstrera ert projekt för labbhandledaren. Två specifika labbtillfällen är reserverade för detta. Det går även bra att demonstrera tidigare om handledaren har tid, men vi bedömer ändå alla projekt tillsammans efter deadline.

Vi har strikta instruktioner för inlämning. Vi har över 130 studenter, så om vi behöver lägga ner 10 minuter extra per student "i onödan" tar det över 20 timmar som vi kunde ha lagt på handledning och kursutveckling! Därför måste vi returnera labbar som inte följer instruktionerna för komplettering.

1. Labben måste lämnas in i IDEA-format så att vi snabbt kan öppna den och navigera genom koden.

   Har du använt en annan miljö: Skapa ett nytt projekt enligt instruktionerna i labb 1. Kom ihåg att ändra More Settings / Project format till ".ipr (file based)"!

2. Läs genom de allmänna kvalitetskriterierna en gång till och se till att koden uppfyller dem.

3. Kör IDEAs kodinspektioner. Det här är till stor del ett sätt att lära sig skriva kod som inte bara gör vad den ska utan även är välskriven och strukturerad.

   Förstår du inte en varning? Utmärkt! Då har du en chans att lära dig något nytt, redan innan du lämnar in koden! Läs IDEAs inbyggda beskrivningar, läs våra utökade beskrivningar, och om det inte hjälper, fråga gärna assistenten eller examinatorn.

   1. Välj Analyze | Inspect Code i menyn.
   2. Välj inspektionsprofil "TDDD78-2015-v1" och tryck OK.

   Inget automatiskt inspektionsverktyg är 100% korrekt. Det kan alltså finnas varningar som är "felaktiga". Alla sådana måste kommenteras på plats i koden, med god motivering. Övriga varningar ska korrigeras. Se även de allmänna kvalitetskriterierna.

4. Är detta en komplettering? Beskriv i så fall i filen "kompletteringar.txt" hur varje enskild kommentar från handledaren har hanterats: Vad som ändrats och var i koden, hur ni har löst problemet, och annan information som är relevant för att handledaren lätt ska se vad som gjorts.

   Gör ni flera kompletteringar ska gamla kommentarer vara kvar och tydligt skilda från nya kommentarer (markera med kompletteringsdatum). Detta underlättar för oss och är en del av examinationen där ni visar att ni förstår varför kompletteringen behövdes.

5. Packa all källkod och andra filer som krävs tillsammans med ev. kompletteringsbeskrivning i en ZIP- eller TAR.GZ-fil. Även den uppdaterade projektbeskrivningen i PDF-format ska ligga i denna fil. Använd t.ex. File | Export to PDF i OpenOffice Writer.

   IDEAs projektdefinitionsfiler (.ipr, .iml) och liknande måste finnas med så att projektet enkelt kan öppnas i IntelliJ IDEA. Testa genom att packa upp arkivet på annan plats och öppna det i IDEA genom att klicka på den nyss uppackade .ipr-filen!

   Döp filen enligt följande mönster, utan mellanslag i filnamnet. Vid komplettering använder ni versionsnummer "v2", "v3" och så vidare. Använd nytt versionsnummer oavsett hur liten kompletteringen är.

   • liuid123-liuid456-projekt-v1.zip

6. Dubbelkolla och trippelkolla att inlämningen är gjord på rätt sätt. Inlämningar som har många okommenterade varningar, saknar nödvändiga filer eller uppenbart bryter mot viktiga regler kommer att returneras utan bedömning.

7. Skicka in filen via epost – till handledaren. Brevets ämne ska inledas med kurskoden TDDD78 så det kan sorteras rätt. Annars kan det dröja innan brevet blir läst.