Om ni arbetar i grupp måste ni ändå utvecklas individuellt. Den ena personen i labbgruppen får inte skriva det mesta av koden "för att det skall gå fortare". Ni ska båda göra ungefär lika stor del av både design och kodning, och båda ska vara fullt insatta i hur saker fungerar.

Om ni arbetar separat på vissa delar av koden måste ni därför regelbundet (gärna varje dag) gå genom den kod som skrivits och diskutera hur den fungerar. Denna informella code review är inte tidsslöseri utan ett utmärkt sätt att både lära sig av andra och hitta problem i programkoden innan det är "för sent"!

I verkligheten krävs i många projekt att all ny kod verifieras på detta sätt innan den överhuvudtaget får integreras i kodbasen.

1. Måndag 140224: Officiell start för projektet.

2. Fredag 140314: Halvtidskontroll. Lämna gärna in nuvarande version, så tar vi en snabb titt på den och kan eventuellt ge några råd och tips.

3. Onsdag 140409: Här, om inte tidigare, är det dags att börja lägga all energi på putsning, buggfixande och dokumentation.

4. Tisdag 140415, onsdag 140416: Projektdemo för grupperna ACEG respektive BDFH. Hos de grupper som vill demonstrera ska alla gruppmedlemmar vara närvarande för att svara på frågor (som på en tenta). Ingen vanlig handledning vid detta tillfälle.

   Kan någon medlem inte komma hänvisar vi till omredovisningstillfället i juni. Grupper som inte är klara kan också redovisa i juni, men vi rekommenderar er att arbeta hårt för att vara klara i tid.

5. Onsdag 140423: Deadline för inlämning av kod.

6. Onsdag 140507: De grupper som har demonstrerat och lämnat in kod i tid, i korrekt format, utan okommenterade IDEA-varningar, ska ha fått feedback för eventuella kommentarer. (Kompletteringar, även enkla kompletteringar, kan dröja längre men hanteras så snabbt vi hinner.)

7. Omtenta-p 140609-140612 (exakt datum meddelas senare): Möjlighet till omdemonstration (eller första demonstration, för den som inte "gick upp" på första demonstrationen). Handledarna kommer vid utsatt tid och går då ingen mer är redo för demonstration. Var förberedda!

   Vid detta extratillfälle: Bedömning och betygsättning inom en kalendermånad.

8. Augustiperioden: Möjlighet till omdemonstration (eller första demonstration). Handledarna kommer vid utsatt tid och går då ingen mer är redo för demonstration. Var förberedda!

   Vid detta extratillfälle: Bedömning och betygsättning inom en kalendermånad.

För att projektet ska få godkänt måste det uppfylla dessa krav. Vissa kraven är tyvärr omöjliga att kvantifiera på ett sätt där man omedelbart ser när man har uppnått nivån för ett visst betyg: Var går gränsen för "god läsbarhet"? Diskutera gärna med labbhandledaren för att få preliminär feedback.

1. Skrivet i Java 7. Används andra klassbibliotek och fritt tillgängligt material, t.ex. bilder eller ljud, ska detta vara tydligt nedskrivet i projektbeskrivningen.

2. Tillräcklig kvalitet. Svårläst, buggig och ostrukturerad kod är stora minus. Ett första steg är att följa de allmänna kraven på programkod, samt de allmänna kriterierna för bra objektorientering som diskuterats på föreläsningarna.

3. Det måste synas att ni har lärt er objektorienterade och Java-relaterade begrepp och vet hur dessa ska användas. Ett projekt som fokuserar helt på "lågnivåprogrammering" är alltså inte aktuellt. Om ett problem kan lösas på ett OO-sätt eller ett icke-OO-sätt ska ni 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, är det normalt subtypspolymorfism som ska användas.

4. Tillräcklig 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 30 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 sätter betyg efter antal kodrader!. Vi använder många andra kriterier som också har att göra med bland annat "svårighetsgrad", 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 kortfattad lösning är oftast bättre än en lång. Ineffektiv kod, t.ex. projekt där identisk eller nästan identisk kod upprepas på flera ställen, kan ge komplettering.

   • Vår rekommendation: Fokusera främst på kvalitet, funktionalitet och att utnyttja era timmar väl. Om ni är oroade över omfattningen, fråga främst er labbhandledare. I sista hand, räkna kodrader för att få en allmän uppfattning.

5. Dokumentation: En projektbeskrivning enligt nedan. Projektkoden måste också dokumenteras enligt de allmänna kodkraven. Det är lämpligt att ha Javadoc-kommentarer för alla klasser. Kod som är viktig, icke uppenbar eller potentiellt svår att förstå måste också dokumenteras. Tänk på att handledaren och examinatorn ska läsa genom hela projektet!

Projektet ges betyg 3, 4, 5 eller komplettering. För de högre betygen ställs högre krav inom dessa tre områden:

• Bra användning av objektorientering och Java (t.ex. polymorfism där detta passar)
• Hög kodkvalitet (välstrukturerad, läsbar, tillräckligt dokumenterad)
• Projektets omfattning (till viss del)

För varje betygsnivå finns även följande rent kvantitativa krav. Hur ni uppfyller kraven ska dokumenteras i projektbeskrivningen. Instruktioner för dokumentation finns där.

Krav	Betyg 3	Betyg 4	Betyg 5
Ett visst antal designmönster måste implementeras och användas, för att ni ska visa att ni behärskar dem. Designmönstren måste användas på ett lämpligt sätt, dvs. varje mönster måste användas för att implementera funktionalitet där det mönstret faktiskt passar. Detta kan till viss del påverka vilken funktionalitet ni väljer att införa i projektet! Ni ska 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. Att använda en existerande Iterator räknas inte heller. Godkända designmönster inkluderar alla mönster från Design Patterns av Gamma, Helm, Johnson och Vlissides. Fråga examinatorn i förväg om ni vill tillgodoräkna er andra mönster och ge en referens till det mönster ni undrar över.	1 mönster	2 mönster	3 mönster
För varje betygsnivå måste ni peka ut hur ni har använt ett visst antal olika typiska egenskaper hos just objektorienterade språk. Typiska egenskaper hos objektorientering inkluderar t.ex. ärvning (där en klass ärver implementerade metoder och fält från en annan), overriding, interface som ett sätt att specificera en abstrakt datatyp, och användandet av sen/dynamisk bindning för att anropa "rätt" implementation av en metod utan att känna till objektets verkliga typ. Icke-typiska egenskaper är t.ex. enum-konstanter, som finns i olika former i många icke-OO-språk som C, och serialisering av datastrukturer.	1 st	2 st	3 st
När man har flera någorlunda rimliga alternativ för hur programmet ska designas och struktureras, och sedan väljer ett av dessa beslut, gör man ett designbeslut. För varje betygsnivå måste ni beskriva ett visst antal designbeslut ni har tagit. Anledningen är både att ni ska visa oss hur ni har tänkt och att ni själva ska fundera och reflektera över era val. Designbesluten ska vara på rimligt hög designnivå, dvs. inte varför ni valde att använda "int" istället för "long" för ett visst fält. 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.	2 beslut	5 beslut	8 beslut
För varje betygsnivå måste 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 bör bara finnas med i diagrammen om de är relevanta (dvs, undvik dem om ni bara vill illustrera klasstrukturen).	1 diagram	2 diagram	4 diagram

Demonstrationen går till så här.

• Demonstrationen inleds med att ni själva demonstrerar funktionaliteten i projektet under några minuter. Var beredda på att visa hur det används och att visa upp de finesser ni själva tycker är viktigast givet tidsbegränsningen.

• Därefter fortsätter handledaren med egna tester och frågor. Bland annat kan vi testa er kunskap om koden och att kontrollera att ni vet varför ni har gjort som ni har gjort. Frågorna kan ställas till en specifik person. Se därför till att alla känner till alla aspekter av koden.

  Detta garanterar inte att alla problem upptäcks – inte ens de som kan verka "uppenbara". Den riktiga genomgången av programkoden sker efter inlämning, när handledaren får tid att sätta sig en timme eller två med enbart ert projekt!

• Labbhandledaren kan också välja att ställa några (individuella!) frågor runt objektorienterad programmering: Vad menas med polymorfism? Varför vill man gömma information? Vad är skillnaden på ärvning mellan klasser och när man implementerar ett gränssnitt? Varför kan designmönster vara bra? Vad finns det för relation mellan meddelanden och metoder? Och så vidare. Var beredda på att svara.

• Om projektet är buggigt kan handledaren välja att gå vidare till en annan grupp så att ni får försöka igen senare. Är programmet för buggigt när demotillfället närmar sig sitt slut kan ni bli hänvisade till omredovisning under nästa planerade demotid, vilket kan dröja.

• När allt är klart lämnar ni in det ifyllda labbomslaget som ni förberedde.

Ni behöver inte lämna in projektbeskrivningen vid demonstrationen.