Göm menyn

Projektförberedelser

Projektets syfte

Projektuppgiften ska:

  • Låta er designa och implementera ett eget OO-program utan att ni är helt bundna av detaljerade instruktioner eller ett givet kodskelett.

  • Vara ett lärtillfälle där ni ständigt funderar och reflekterar, inte bara över hur man får programmet att bete sig på rätt sätt utan även över hur man strukturerar koden rätt. Vad programmet gör är oftast inte lika viktigt som hur det gör det.

  • Låta er demonstrera era kunskaper inom objektorientering. Det inlämnade materialet är ert sätt att visa vad ni har lärt er av kursmaterial, praktiskt arbete och reflektioner.

Projektet väljs fritt, inom vissa gränser som diskuteras nedan.

Projektet motsvarar ca 80 timmars arbete per person (3 hp). Omkring en fjärdedel av detta är handledd schemalagd tid. 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.

Anmälan till projekt

Under projektet får man gärna arbeta i par. Detta kan ha många fördelar, så vi och många tidigare studenter rekommenderar det. Man kan även arbeta enskilt om man föredrar eller inte hittar en partner. Vi tar självklart hänsyn till detta i bedömningen, men tänk på att pararbete inte innebär att två personer gör varsin halva utan kommunikation. Alltså kan den som arbetar enskilt inte nöja sig med att nå hälften så långt. Större grupper än två är inte tillåtna.

De 5 nya "storgrupperna" för projektet hanteras som vanligt via WebReg:

  • Om ni har gått någon av kurserna tidigare läser ni först den nya sidan för återvändande deltagare. Sedan kontaktar ni examinatorn för att bli adderade till Webreg. I vissa fall kommer vi att fortsätta registrera resultat under en tidigare anmälan istället för att ni anmäler er på nytt.

  • U:are som går TDDD78 för första gången anmäler sig i U1-G24 eller U1-G25. Båda grupperna fungerar för både U1A och U1B.

  • D:are som går TDDE30 för första gången anmäler sig i D1-G21, D1-G22 eller D1-G23. Båda grupperna fungerar för alla klasser.

  • Vill ni samarbeta mellan D och U behöver ni välja en grupp ni vill gå i (21-25), och sedan kontaktar ni examinatorn så vi kan se till att det fungerar korrekt med betyg på er egen kurskod.

  • Kognitionsvetare som går 729A85 för första gången anmäler sig via epost till examinatorn. Ni kommer att labba tillsammans med TDDE30.

Om det är fullt i alla grupper ni kan anmäla er i, vänta lite eller kontakta examinatorn.

Regler: Grupparbete sker i grupp!

Även när man arbetar i grupp måste man utvecklas individuellt. Den ena personen i gruppen 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.

Välja projekt: Allmänna kriterier

Att välja projekt är oftast inte helt lätt. Här kommer några krav och tips. Konkreta exempel visas senare.

  • Projektet ska leda till ett demonstrerbart program. Skriver man någon form av "kodbibliotek" måste det alltså också finnas ett program som använder sig av kodbiblioteket, där det mesta av koden faktiskt används.

  • Ni ska inte fortsätta med Tetris. Ni bör inte heller fastna alltför hårt i strukturen från Tetris, även om ni väljer att implementera ett spel. Ett Breakout-spel är till exempel väldigt nära Tetris eftersom det mest handlar om rutor i ett rutnät, och där "räknas inte" koden som har samma grundstruktur som Tetris utan ni behöver lägga till betydligt mer nytt.

  • Projektet bör ha en liten kärna som är lätt att utöka i många steg. Det är ju inte lätt att uppskatta exakt vad man kommer att hinna med på de 80 timmar man har för design, kodning, finputsning och dokumentation. Kan projektet byggas upp steg för steg, kan ni "programmera till tiden tar slut" och sedan avsluta. Då kan ni balansera projektets omfattning mot dess kvalitet.

    Detta återkommer i projektplanen, där projektet delas upp i ett antal milstolpar.

  • Ni måste kunna visa upp hur ni uppnått målen i just denna kurs. Med andra ord, använd projektet till att lära er mer om just objektorientering, och visa upp i slutresultatet att ni kan utnyttja OO och Java på ett bra sätt. Ni behöver alltså ett projekt där ni aktivt använder klasser, ärvning, polymorfism, inkapsling av information, och så vidare.

    Detta går bra i de flesta projekt, så oroa er inte alltför mycket – men ibland blir det för stark tyngdpunkt på annat. Sådana projekt ska undvikas, även om de är roliga och intressanta ur ett "allmänt" programmeringsperspektiv! Ett par exempel:

    1. Android-projekt kräver mycket Android-specifik programmering som inte är direkt OO/Java-relaterad. Givet vår erfarenhet från tidigare år avråder vi starkt från detta.

    2. Bildbehandlingsfunktioner kräver mycket matrismatematik men kan ge ont om tid till användning av polymorfism, designmönster, osv.

    3. Om man inte tänker sig för kan vissa actionspel sluta med alltför mycket manipulering av skärmkoordinater och alltför lite objektorienterad programmering. Det beror till stor del på hur mycket man fokuserar på rörelser, utseende på skärmen, kollisionsdetektering, och så vidare. I de flesta spel kan man istället välja att fokusera mer på de olika typerna av entiteter som behövs i spelet (spelare, fiender, brickor, föremål, powerups, ...), hur man modellerar deras likheter och olikheter (ärvning i vissa fall men inte lämpligt i andra), och så vidare.

  • Undvik tidskrävande svårigheter som inte är kursrelaterade. Till exempel:

    1. Snygg grafik tar mycket tid. Eftersom detta inte är en designkurs kan vi inte premiera detta i bedömningen. Gör hellre enkel grafik och koncentrera er på programmering och OO.

    2. Snygga animeringar kan ta tid. Låt hellre rörelser förbli en aning hackiga, om de nu skulle råka vara det, och spendera mer tid på OO.

    3. Synkronisering över nätverk i realtid är mycket svårt. Det kan vara väldigt roligt att implementera ett nätverksspel för flera spelare, men håll er i så fall till brädspel eller liknande. Att utveckla t.ex. ett plattformsspel där spelarnas förflyttningar och andra händelser synkroniseras i realtid över nätet är mycket svårare än man kan tro. Det har hänt att grupper spenderar veckor bara på att få en bra implementation av denna synkronisering, och eftersom detta varken är en nätverkskurs eller en spelkurs är denna svårighet inget vi kan premiera i bedömningen!

  • Var försiktig med externa klassbibliotek och ramverk.

    1. Vi som håller i kursen har tillsammans goda kunskaper om de centrala klassbiblioteken i Java. Om ni vill använda alternativa bibliotek och ramverk är det tyvärr "på egen risk". Det kan hända (har hänt) att kursdeltagare får problem med ramverk som inte vill fungera som de borde. Vi kan hjälpa till så gott det går under schemalagd labbtid men vi har inte möjlighet att ta extra tid till detta.

      Exempel på klassbibliotek som har lett till problem de senaste åren: Smack.

    2. Vissa externa ramverk är verkligen ramverk, i betydelsen att det är ramverket som driver den resulterande applikationen framåt, medan den som använder ramverket ska fylla i hålen och plugga in kod i vissa delar. Smack fungerar uppenbarligen så i viss mån, liksom Androids GUI-system.

      Meningen med projektet är att ni ska driva allt framåt. Ni får använda hjälpfunktionalitet från andra platser, men den ska då vara just hjälpfunktionalitet.

Välja projekt: Exempel

För de som inte vill hitta på ett eget och helt unikt projekt har vi följande förslag som inspiration, delvis "påhittade" och delvis från projekt som tidigare kursdeltagare har genomfört. De olika funktionerna hos programmen är bara exempel. Välj och vraka, och kombinera beroende på vad ni har tid för och är intresserade av – och ge gärna egna förslag till framtida kurser!

  • Ett vektorritprogram / CAD-program. Här kan man göra en enkel grund och sedan bygga på gradvis med olika former, ritverktyg, och så vidare.

  • En CPU-emulator där man kan köra små program för en påhittad eller verklig CPU-arkitektur. Här kan man bygga på med fler instruktioner, med visualisering av vad som händer i CPUn i varje steg, med funktioner för att spara och ladda program, och så vidare.

  • Ett brädspel för två spelare, med nätverkskoppling mellan spelarna. Brädspel brukar inte ha realtidskrav och är därmed relativt enkla att synkronisera över nätet. Detta är en stor skillnad jämfört med actionspel där millisekunderna spelar roll och där det kan vara mycket svårt att få ett konsistent gemensamt tillstånd. Det går också bra att göra en enkel kärna som sedan utökas med att ladda och spara spelpositioner, med animerad flyttning av spelpjäser, med en enkel AI-spelare, och så vidare.

  • Ett kalenderprogram där användaren kan boka tider. Tänkbara finesser: Visa grafiskt i olika vyer. Kanske drag-and-drop i den grafiska vyn? Sökning. Utskrift av schema. Export till standardiserade kalenderformat.

  • Ett icke nätverksbaserat grafiskt "actionspel", till exempel ett plattformsspel. Spel i stil med Breakout kan vara problematiska eftersom de är väldigt lika Tetris, så välj gärna något annat, till exempel ett ett plattformsspel. Tänk dock på att animering, kollisionshantering och liknande kan vara krångligt, särskilt om man inte har hållt på med det förut.

  • Ett grafiskt ZIP-verktyg. Java har inbyggt stöd för ZIP-formatet i paketet java.util.zip. Lägg till filer, extrahera filer, testa arkiv, sortera fillistan i olika ordning...

  • Ett system för att skapa, visa och skriva ut UML-diagram från existerande Java-klasser, med möjlighet att manipulera diagrammen på skärmen.

  • En Instant Messaging-klient för ett existerande öppet och känt protokoll, till exempel Jabber/XMPP.

  • En ljuddesigner där man kan skapa ljud med FM-syntes, med grafisk redigering.

  • Ett budgetprogram där man kan hantera konton, transaktioner och en budget.

  • Ett schemaprogram med gränssnitt mot TimeEdit, där man kan hålla reda på sitt schema, hitta lediga salar, och så vidare.

Välja projekt: Detaljerade exempel för TDDD78

Om du går TDDD78 har du mindre tid på dig att välja och utarbeta ett projekt. Då kan du välja att ta emot mer detaljerad inspiration från något av följande exempel. Notera att dessa beskrivningar ska ge just inspiration. De måste inte följas till punkt och pricka, och du kan mycket väl behöva göra egna tillägg för att komma fram till ett lagom stort eget projekt!

Även med inspirationsprojekt måste man skriva projektplan! Se nedan.

Även du som går TDDE30 kan välja att inspireras av någon av dessa beskrivningar, men eftersom du har mer kalendertid att fundera på projektet hoppas vi att du verkligen tar tillfället att anpassa det till vad du själv vill göra!

Projektplanering

Innan ni börjar utföra projektet behöver ni skriva en projektplan, oavsett om ni valde ett inspirationsprojekt som planen inspireras av eller väljer att göra något helt eget. Skriv på svenska, oavsett handledare. 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 ni ska tänka genom hur ni ska arbeta, om ni arbetar i par. Det är viktigt att komma överens om när/hur man arbetar och vad ambitionen är!

  3. Att er handledare ska kunna ge feedback om det finns stora och uppenbara problem.

Att göra: Beskriv projektet

Fyll tillsammans i planeringsdelen av projektbeskrivningsmallen. Mer instruktioner ges i denna.

Att göra: Skicka till handledaren

Om ni går TDDD78 (VT1):

  • Om ni har använt ett inspirationsprojekt måste ni inte lämna in projektplaneringen i förväg, men ni får gärna göra det för att få en möjlighet till feedback.

  • Om ni har hittat på ett eget projekt ska ni lämna in projektplaneringen så snart som möjligt, så att vi kan se att ni inte är inne på uppenbart fel väg.

Om ni går TDDE30/729A85 (VT1 + VT2):

  • Ni måste lämna in projektplaneringen. Lämnar ni in före deadline kan vi garantera att ni får eventuell feedback innan projektstart. Annars kommer vi att titta på projektplanen när vi har tid och möjlighet.

Instruktioner för dig som lämnar in:

  1. Exportera till PDF-format, t.ex. med File | Export to PDF i OpenOffice Writer. Döp filen enligt följande mönster, utan mellanslag i filnamnet. Ditt eller era LiU-ID måste alltså finnas med.

    liuid123-liuid456-projektplan.pdf

  2. Skicka till er egen handledare för en kort genomgång. Brevets ämne ska som alltid inledas med kurskoden (TDDD78, TDDE30 eller 729A85) så det kan sorteras rätt.

Om granskningen

Det är omöjligt för handledarna att helt och hållet avgöra hur genomförbart ett projekt är. Därför är genomgången är en kortare "sanity check" där vi tittar efter uppenbara problem, som att projektet är alldeles för litet eller för stort eller att ni saknar tillräcklig information om milstolpar. Vi ger inte "godkänt" eller "ej godkänt" på detta i webreg, utan ger "inlämnat" som betyg om vi inte ser något uppenbart att diskutera. Ansvaret för projektets innehåll ligger fortfarande på er som kursdeltagare, och ni får gärna fortsätta diskutera detta med era handledare under labbarna medan ni utför projektet.


Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2019-04-04