Projekt
För att komma igång med projekten kommer första halvan av föreläsningen den 10/12 att ägnas åt att introducera projektuppgiften och upplägget - då är det bra om så många som möjligt dyker upp (även ni som normalt inte går på föreläsningarna). För att lösa projektuppgiften behöver ni kunna objektorienterad programmering och till viss del även analys och design. För VG kräv även att ni uppfyller några avancerade krav, varav ett alternativ kommer att innefatta ett grafiskt gränssnitt (se Fö 8).
Projektuppgiften innefatta att skapa ett lite större program på egen hand, som uppfyller ett antal "kundkrav" - dvs som löser en uppgift men utan att ni får detaljerade instruktioner HUR uppgiften ska lösas. Kraven kommer att ha två nivåer: för att få G på projektet krävs att alla baskraven är uppfyllda, och för att få VG kommer det krävas att ytterligare något av de avancerade kraven är uppfyllda.
Planering, utförande och deadlines
Projektuppgiften genomförs och redovisas i samma grupper som labbuppgifterna, dvs två och två. Inlämning sker genom It's Learning precis som för labbarna. Ni jobbar med projektuppgiften parallellt med labbarna under hela del 2 av kursen, men ni har två extra veckor på slutet av kursen (efter deadline för labbarna i del 2) att fokusera helt på projektuppgiften. Observera att detta är en ganska omfattande uppgift - lämna inte all programmering till dessa två sista veckor, då riskerar ni att inte hinna färdigt!
För projektet finns tre delmål med följande deadlines (alla är obligatoriska för att kunna få VG, för G gäller att allt måste vara godkänt innan kompletteringsdeadline):
- Deadline för att diskutera er design med handledaren: 20/12 2012 - boka ett möte med handledaren, visa upp designen på ett labbtillfälle, eller kom överens med handledaren att ni skickar er design (beskrivning av scenarion och klassdiagram) via e-post.
- Deadline för att demonstrera (=visa upp) ert färdiga program för handledaren: 22/2 2013 - boka ett möte med handledaren i god tid före deadline, eller visa upp designen på ett labbtillfälle (i mån av tid - fram till 31/1 prioriterar handledarna att svara på frågor om labbarna). Båda medlemmarna i gruppen ska vara beredda att svara på frågor om koden och hur ni har löst olika problem.
- Deadline för att lämna in : 22/2 2013 - ladda upp en zip-fil som innehåller (1) all kod för er lösning, (2) html-filer för er Javadoc, (3) projektrapporten (i pdf eller Word-format).
Komplettering av projektuppgiften måste ske innan 28/3 2013 - efter detta datum kan ingen komplettering av projektet ske, och studenter som inte blivit godkända hänvisas till nästa års kurs. För komplettering av demonstrationen boka tid med handledaren i mycket god tid. För komplettering av inlämnat material öppnar inlämningen i It's Learning åter i god tid innan kompletteringdeadline.
Examination och betygsättning
För betyg G på projektuppgiften krävs följande:
- Ert program har all funktionalitet som beskrivs i kravlistan för betyg G.
- Ni har diskuterat er design med handledaren, helst före 20/12.
- Ni har demonstrerat ert projekt för handledaren senast den 22/2 (eller åtminstone före kompletteringsdeadline 28/3) med godkänt resultat och kunnat svara på handledarens frågor om hur ni har löst problemen.
- Ni har lämnat in ert färdiga program (kod + Javadoc + rapport) senast den 22/2 (eller absolut senast före kompletteringsdeadline den 28/3) och handledaren har godkänt er lösning. För att lösningen ska bli godkänd krävs:
- Välstrukturerad kod - dvs ni använder det ni har lärt er i kursen genom att dela upp programmet i lämpliga klasser fördelade över lämpliga paket. Klasser, variabler och metoder har lämpliga modifierare för åtkomst mm, och ni tillämpar objektorienterade principer såsom inkapsling.
- Välkommenterad kod - dvs ni har kommentarer i er kod som förklarar vad ert program gör. Minst varje block av relaterad kod måste ha en kommentar, t ex varje if-sats, varje loop osv. Dessutom ska alla publika klasser, metoder och variabler vara kommenterade så att de återfinns i Javadoc-dokumentationen.
- Vältestad kod med felhantering - dvs ert program ska kunna hantera de flesta situationer utan att "krascha", t ex ska felaktig inmatning från användaren inte leda till att programmet avslutas, utan detta ska tas om hand och åtgärdas. Var noga med att testa ert program både med förväntade inmatningar, men även med felaktiga och oväntade eller slumpvisa indata, för att vara säkra på att programmet kan hantera detta.
- En projektrapport som följer den givna mallen (finns här på hemsidan), och som inte innehåller några stavfel eller grammatikfel i texten (använd stavningskollen i ordbehandlingsprogrammet).
För betyg VG på projektuppgiften krävs allt som gäller för G, samt dessutom följande:
- Alla deadlines är strikta, dvs ni måste diskutera er design med handledaren innan 20/12, samt demonstrera och lämna in er lösning innan den 22/2 - ni kan inte vänta till kompletteringstillfället. (Däremot går det bra att komplettera lösningen senare om handledaren inte direkt godkänner lösningen utan kräver komplettering.)
- Ni har utökat programmets funktionalitet i enlighet med ett av de tre alternativ som finns i beskrivningen av projektuppgiften, dvs antingen har ni (1) bytt ut det textbaserade gränssnittet mot ett grafiskt gränssnitt, eller (2) bytt ut datalagringen genom vanliga filer mot en databaskoppling, eller (3) utökat funktionaliteten i enlighet med de nya kraven i alternativ 3.
Observera att i undantagsfall kan medlemmarna i en projektgrupp få olika betyg på uppgiften. För att få VG på projektuppgiften måste den enskilda gruppmedlemmen kunna beskriva gruppens lösning och svara på frågor om lösningen, om kraven för VG i övrigt är uppfyllda men en gruppmedlem inte kan redogöra för lösningens innehåll kan den studentens betyg sänkas till G eller U. Reglerna för plagiat är desamma som för labbuppgifterna: det går bra att diskutera sin lösning med andra grupper, men ni får inte kopiera en annan grupps lösning - dvs varken "skriva av" en lösning och ändra namn och kommentarer, eller att faktiskt kopiera kod är tillåtet.
Genomförande av projektet
För att genomföra projektet ska ni gå igenom följande faser (för betydelsen av faserna se Fö 6):
- Kravanalys
- Design
- Implementation
- Dokumentation
Kravanalys och design ska vara avslutat senast 20/12, medan implementation och dokumentation pågår parallellt från det att analys och design är avslutade och ända till projektets slut.
Efter analysfasen ska ni, baserat på kraven, kunna svara på följande frågor:
- Vilka objekt finns?
- Vad har de för attribut/egenskaper?
- Vad har de för beteenden/vilka tjänster erbjuder de?
- Vilka scenarion måste systemet kunna hantera? - Scenarion är beskrivningar av typiska situationer, händelseförlopp, där systemet deltar.
- Hur samarbetar objekten (över tid) för att lösa dessa scenarion?
Efter designfasen ska ni, baserat på kraven och resultatet av analysfasen, kunna svara på följande frågor:
- Vilka klasser ska programmet ha?
- Vilka variabler ska varje klass ha och vilken datatyp ska varje variabel ha?
- Vilka metoder ska varje klass ha, vilken returtyp har varje metod, och vilka parametrar tar de som indata?
- Kan vi effektivisera systemet genom att generalisera klasser och låta subklasser ärva variabler och metoder? Hur ser i så fall klasshierarkin för programmets klasser ut?
- Hur är klasserna relaterade till varandra i övrigt, dvs vilka klasser använder/kommunicerar med vilka andra klasser i de scenarion ni beskrivit?
- Hur ska huvudprogrammet ("main"-metoden) se ut (beskriv gärna med pseudokod)? I vilken klass ska "main"-metoden finnas?
Använd gärna de olika typerna av diagram som visades på föreläsning 6 för att rita upp svaren på ovanstående frågor, men det är inget krav. Ett scenario är en typisk situation som systemet ska kunna hantera. Exempel på scenarion för projektuppgiften kan vara "sätta in pengar", "ta ut pengar", "betala av på lånet" osv. Beskriv scenarion i textform, gärna som exempel i stil med "Anders kommer till banken och ska ta ut pengar...". När ni känner er klara med analys och design - prata med er handledare. Har ni ritat upp er design och skrivit ner scenarion i ett elektroniskt dokument, kan ni maila detta till er handledare, men i de flesta fall är det bättre om ni pratar direkt med handledaren (boka tid, eller träffa honom/henne på ett labbtillfälle). Handledaren kommer att vilja höra vad ni har för svar på ovanstående frågor, diskutera de scenarion som ni har beskrivit, och se ert detaljerade klassdiagram från designfasen (om ni inte har ritat detta i form av ett diagram ska ni ändå kunna berätta vilka klasser som ska ingå, vilka metoder de har, osv.) Senast den 20/12 ska ni ha diskuterat er design med handledaren!
Sedan är det dags att börja implementera er design. Använd er gärna av pseudokod för att först beskriva hur ni tänker implementera huvudprogrammet, samt klassernas metoder, "på papper" innan ni börjar att programmera. Det underlättar och minskar risken att fastna om ni har en klar bild av vad metoden ska göra och vilka steg som behövs innan ni börjar skriva själva koden. Dokumentera koden kontinuerligt, dvs skriv kommentarer direkt när ni skriver koden, lämna inte detta till sist - då kanske ni själva har hunnit glömma vad en viss metod gör! Börja även skriva på projektrapporten i god tid innan inlämning.
För er som siktar på VG:
- Välj det extrakrav som ni antingen känner er mest hemma med, eller som ni vill lära er mer om. Dvs har ni programmerat grafiska gränssnitt tidigare, eller kanske jobbat med databaser, kan ni antingen välja ett av de två första utökade kraven - eller så väljer ni ett som ni inte kan något om och vill lära er mer om. Observera att tanken är att ni själva ska läsa in er på området, så förvänta er inte att alla handledare kan ge detaljerad hjälp om alla klasser ni kan komma att behöva! Är ni nya på programmering rekommenderas att ni väljer alternativ 3: att "bara" utöka programmet med extra funktionalitet, vilket troligen är det lättaste alternativet om ni inte har programmerat tidigare.
- Även om ni tänker satsa på VG, börja med att implementera en lösning för de grundläggande kraven, så att ni är säkra på att ni hinner med detta innan deadline. Dvs lägg inte för mycket tid på VG-kraven i början så att ni riskerar att inte ha någon fungerande lösning alls när det är dags att lämna in!
Kravspecifikation
Här hittar du kravspecifikationen för projektuppgiften. För betyget G behöver ni bara läsa första sidan, för att kunna få VG behöver ni uppfylla kraven både på sida 1 och 2.Projektrapporten
Här hittar ni ett Word-dokument som ni ska använda som mall för er projektrapport. Ni måste ha med alla rubriker som finns i mallen, och det innehåll som beskrivs under rubrikerna. Rapporten måste vara minst 6 sidor lång inklusive framsida, men ni får gärna skriva lite längre (dock är vi som rättar tacksamma om ni inte skriver för långa rapporter - runt 10-12 sidor kan ni se som en maxgräns). Vill ni skriva i något annat program än Word går det bra, se bara till att följa mallen så noggrant ni kan, och observera att ni måste lämna in dokumentet antingen som en Word-fil eller som en pdf.
Sidansvarig: Eva Blomqvist
Senast uppdaterad: 2013-02-01
