Göm menyn

TDDI82 Objektorienterad problemlösning

Projekt


Innehållsförteckning

  1. Allmän info
  2. Gruppindelning
  3. Gruppkontrakt
  4. Projektbeskrivning
  5. Git och versionshantering
  6. Arbetsprocess
  7. Individuell statusrapprt
  8. Krav på projektet
  9. Projektredovisning
  10. Kodinlämning samt kodgranskning

Allmän info

I denna kurs ska ni i grupper om fyra studenter utföra ett projekt. För att öva på planering, kommunikation och utförande så kommer dessa grupper slumpas av kursledningen. Projektet ska resultera i att era färdigheter inom objektorienterad problemlösning visas upp och förbättras. Exakt vad för projekt ni ska göra är upp till er som grupp, men typiskt brukar vi rekommendera att man programmerar ett enklare datorspel. Fokus i denna kurs är på programmering och planering av ett objektorienterat system, så vi kommer inte kräva särskilt mycket dokumentation eller liknande från er sida.

Om du avser att skriva projektet detta år ska du anmäla dig på länken i menyn till vänster. Du kommer då få en grupp tilldelad till dig inför fjärde föreläsningen i kursen.

På sidan Deadline och viktiga datum hittar ni när varje moment av projektet ska genomföras.

Gruppindelning

Kursledningen kommer slumpa ut gruppindelningar senast 12/4, vilket är lagom till första projektföreläsningen. Då är tanken att ni i pausen på föreläsningen har möjlighet för en första kontakt med gruppen.

Det är viktigt att så fort som möjligt komma överens med gruppen över följande saker:

  • Vad ni ska göra för projekt. Detta kan lättast göras om alla i gruppen tar med sig ett eller två förslag på projektidéer. Sedan kan man i gruppen rösta på vilken idé man vill köra på. Det är inte ett krav att ni gör på detta sätt, men det är ett enkelt sätt att lösa det på.
  • Se till att alla i gruppen är överens om ambitionsnivån. Det är stor variation på typen av projekt som görs och vissa kräver mer jobb än andra. Om ni är osäkra på om er idé är inom en rimlig nivå rekommenderas det att ni pratar med en handledare eller lärare om er idé.
  • Att alla är beredda på att lägga ungefär lika mycket tid på projektet. Kom överens tidigt om hur mycket ni förväntas och är villiga att jobba på projektet.
  • Att ni skriver ett gruppkontrakt gemensamt som sedan skickas till handledare (se nedan).
  • Dela upp arbetet så att var och en har en uppgift som går att arbeta på direkt och en deadline för det. Om någon uppgift beror av en annan måste ni omedelbart ta beslut om precis så mycket att båda uppgifterna går att slutföra oberoende av varandra och sedan sammanfoga. Skjut aldrig upp arbete "som inte går att påbörja ännu", se till att det går att påbörja istället. Be er assistent om tips hur man kan komma igång utan att alla beroenden är klara. Skriv ned de uppgifter och deadline ni kommer överens om för var och en i ett mail som ni skickar till samtliga gruppmedlemmar. Det är bra att ha om det blir strul i gruppen senare.

Gruppkontrakt

Varje grupp ska skicka in ett gruppkontrakt till sin handledare senast 26/4, 17:00.

Detta är ett bra tillfälle att etablera komunikationskanaler och i ett tidigt stadie sätta upp regler.

Krav på gruppkontraktet

  • Alla gruppmedlemmar ska vara involverade i skapandet av gruppkontraktet.
  • Det ska skickas in som en pdf.

Läs igenom Punkt 2 i det utförliga exemplet och diskutera frågorna och skriv ner det ni kommer överens om.
Använd Gärna mallen.

Ni behöver inte skapa hela detta kontraktet utan kommer fokusera på punkt 2: Hur vi arbetar tillsammans i exemplet. Det kan dock vara av nytta att fortfarande gå igenom de punkter som finns i det utförligare gruppkontraktet och disskutera dem tillsammans

Projektbeskrivning

Innan ni börjar med projektet ska ni skriva en kort beskrivning av ert projekt och skicka till er handledare senast 1/5, 17:00. Denna beskrivning ska innehålla följande:

  • Vad ert projekt är. Här ska ni övergripligt beskriva vad ni har tänkt göra och vad för funktionalitet som ska finnas.
  • En bild som representerar hur ni tänker er att projektet ska se ut. Kan vara en bild på ett liknande projekt, eller en handritad skiss.
  • En kort beskrivning på hur ni anser att detta projekt är tillräckligt stort för att uppfylla alla krav (specificerade nedan).
  • Ett enkelt klassdiagram som ni har producerat på workshop lektionen.

Denna beskrivning ska skickas till er tilldelade handledare via E-post senast 1/5, 17:00, på följande format: 

To: <handledare>@liu.se
CC: <LiU-ID>@student.liu.se för samtliga projektmedlemmar
Subject: TDDI82: Grupp N - Projektbeskrivning
Attachment: TDDI82_Grupp_N_projektbeskrivning.pdf
Content:
Något i allmänt positiv anda, t.ex. Här kommer vårt projektförslag!

Git och versionshantering

När grupperna är tilldelade kommer kursledningen skapa ett Git-repo på LiUs GitLab server. Vill ni börja programmera i förväg kan ni skapa ett eget repository i gitlab där ni lägger till alla gruppmedlemmar. När ni får inbjudan från oss kan ni flytta ert repository till det ni får i kursen.

Tanken är att ni aktivt ska arbeta i detta repository. Vi kommer kontinuerligt kontrollera er aktivitet varje fredag fr.o.m. det att ni har fått ert GitLab repository tilldelat tills första fredagen efter projektredovisningen.

Specifikt kommer git-kontroller genomföras:

  • 3/5, 08:00
  • 10/5, 08:00
  • 17/5, 08:00
  • 24/5, 08:00

Under dessa kontroller kommer handledaren kontrollera aktiviteten hos varje gruppmedlem. Aktiviteten kommer bedömas enligt följande skala:

IA: Ingen aktivitet

Detta betyder att inget substantiellt bidrag till koden har pushats till git. Detta får endast förekomma på första git-kontrollen. Om man har två eller fler git-kontroller som har fått denna bedömning så riskerar man att bli underkänd eller att man blir tvungen att fixa alla kompletteringar på projektet helt själv.

Notera: att fixa formattering på kod, ladda upp kodexempel, bilder eller andra resurser räknas inte som ett bidrag till projektet. Utan det är endast bidrag som gör att koden utvecklas som räknas.

LA: Låg aktivitet

Detta betyder att man har gjort några få bidrag, men att dessa bidrag inte är tillräckliga. Om du blir tilldelad denna gradering under en git-kontroll så är det en varning för att du måste jobba mer framöver för att inte riskera att behöva göra en individuell komplettering på projektet.

A: Aktivitet

Detta betyder att du har gjort en bra nivå av bidrag till projektet och att du bör fortsätta i denna takt.

HA: Hög aktivitet

Denna gradering betyder att du har gjort väldigt många substantiella bidrag till kodbasen.

För att detta ska bli så enkelt och rättvist som möjligt så behöver ni sätta upp era lokala git-installationer så att de rapporterar rätt användarnamn samt e-postadress för just dig. Detta görs genom att du på varje dator som du kommer använda under projektets gång skriver följande kommandon i terminalen: 

git config --global user.name "<LiU-ID>"
git config --global user.email "<LiU-ID>@student.liu.se"

Där <LiU-ID> ersätts med ditt LiU-ID.

Om du inte använder git via terminalen så är det ditt ansvar att ta reda på hur du ställer in rätt användarnamn och E-postadress. Notera alltså att vi kommer ignorera commits från okända E-postadresser eller okända användarnamn.

Du kan verifiera att dina inställningar är korrekta genom att skriva: 

git config --get user.name
git config --get user.email

Det kan också verifieras genom att kolla på din git-historik och se om Author fältet är korrekt. Du ser historiken genom att köra följande kommando i terminalen: 

git log

Användbara länkar:

Arbetsprocess

Här följer ett antal tips på hur ni kan lägga upp arbetet:

  • Sitt hela gruppen i närheten av varandra, men ha om möjligt var sin dator
  • Arbeta med din uppgift i en egen branch
  • Rådgör med kamrater eller assistenten om det är svårt komma igång
  • Lös en liten del i taget och committa ofta (headerfil klar, testcase 1 klart, funktion 1 klar, testcase 1 fungerar, osv...)
  • När du har något lite större som fungerar (klass X klar!), merga in din lösning till den gruppgemensamma branchen (main) och se till att din kod både fungerar och används av resten av projektet
  • Kontrollera vad dina kamrater gjort, om det är någon några som inte committat lika mycket som du, försök hjälpa dem komma igång med sina uppgifter
  • Lägg till vad du gjort, hur mycket tid det tog, och hur du tycker gruppens arbete går i en statusrapport (som du bibehåller som underlag till den statusrapport som ska skickas in, samt som underlag för slutredovisningen)
  • Om ni jobbar i par, byt till din kamrats konto (så hen får commits i git)

Någon gång under projektet ska ni ha bokat och genomfört minst ett möte med er handledare. Se följande sida: Möte med handledare för informaton om hur ni bokar ett möte.

Notera även att schemat i TimeEdit har ett antal pass som kallas "Projekt" pass i SU-salarna. Dessa pass är bokningar som ligger för att ni ska ha prioriterad tillgång till en datorsal under dessa tider. Det kommer inte vara några assistenter närvarande på dessa pass. Däremot så är det rekommenderat att ni bokar era handledarmöten under dessa tider.

Individuell statusrapport

En individuell statusrapport ska lämnas in av vardera gruppmedlem senast 9/5, 17:00. Denna statusrapport ska inkludera följande:

  • Hur samarbetet i gruppen fungerar
  • Har du själv kommit igång bra och vet vad du ska göra?
  • Vet du vad alla andra gör?
  • Går arbetet framåt?
  • Tycker du att det är någon som jobbar för mycket eller jobbar för lite?
  • Är det någon i gruppen som går emot gruppen?
Denna statusrapport ska skickas till din handledare via E-post med titeln TDDI82: Statusrapport. Skicka från din LiU mejladdress.

Krav på projektet

Här hittar du kraven som ställs på projektet. Dessa är indelade i två övergripande kategorier: projektkrav och övriga krav. Projektkrav är de krav vi ställer på koden och funktionaliteten av projektet, medan övriga krav är krav vi ställer som handlar om saker runt omkring projektet.

Projektkrav

Typiskt brukar projektet implementeras som ett spel så kraven är designade med spel i åtanke. Däremot är det inte ett explicit krav att det ska vara just ett spel, men det skulle kräva viss diskussion med er assistent för att komma fram till hur ni då ska uppnå kraven.

Projektet ska ha grafik med hjälp av det externa biblioteket SFML

Biblioteket SFML ska användas för att hantera fönster, grafik och användarinmatning samt potentiellt ljud (ljud är inte ett krav).

Projektet ska reagera på inmatning från tangentbord och/eller mus

Detta innebär rent konkret att all interaktion med spelet från användaren ska komma via mus och/eller tangentbord. Det är OK att även ta hänsyn till andra inmatningsmetoder (t.ex. spelkontroller) men det ska då också gå att interagera via mus/tangentbord.

Projektet ska ha minst tre olika skärmar/lägen

Detta innebär att det ska finnas minst tre lägen projektet kan befinna sig i. Om vi tar ett spel som exempel så skulle detta exempelvis kunna innebära att man har en startmeny, själva spelet samt en game-over meny.

Projektets tillstånd ska laddas från en extern resurs

Detta innebär att datan som populerar projektet inte ska hårdkodas. Extern resurs i detta krav är lite löst definierat, men det kan t.ex. vara en eller flera filer eller en slumpgenerator som genererar tillståndet.

Notera: ljud och bilder räknas inte som extern resurs, utan det som syftas till med "projektets tillstånd" är saker så som:

  • Vilka typer samt antalet av objekt som skapas när projektet startar. Detta kan t.ex. vara: hur många fiender, powerups, väggar etc. som initialt finns på banan i ett spel.
  • Initial data för objekten som skapas, t.ex. position, storlek, hälsa o.s.v.

Projektet ska nyttja objektorienterad design

Detta innebär att:

  • inkapsling ska vara korrekt,
  • varje klass ska ha ett ansvarsområde,
  • alla objekt i en arvshierarki ska sparas i en behållare, och sedan ska virtuella funktioner anropas på dem en i taget via basklassens gränssnitt,
  • det publika gränssnittet ska vara så enkelt som möjligt.
I regel kan ni följa SOLID akronymet. Ni kan också följa Objektorienterad programmering i ett nötskal.

Projektet ska bestå av minst tre olika polymorfiska arvshierarkier

I detta sammanhang ska det alltså finnas minst tre olika basklasser som har minst en virtuell funktion var. Notera att det är ok (men inte ett krav) att alla tre arvshierarkier är del av en större arvshierarki.

Det ska finnas minst två härledda klasser i varje hierarki

De härledda klasserna ska variera på både beteende och data. Detta innebär att de ska ha olika datamedlemmar samt att logiken i klasserna ska vara olika. Det är viktigt att notera att beteende refererar till funktionella skillnader.

Minst en av hierarkierna ska ha minst ett arvsdjup på tre

Detta innebär att en av basklasserna ska ha en härledd klass som sedan i sin tur har en härledd klass.

Minst två av hierarkierna ska ha två eller fler virtuella funktioner

Dessa virtuella funktioner ska användas på ett vettigt sätt ur ett objektorienterat perspektiv.

Övriga krav

Här samlar vi krav som inte har med koden att göra, men som fortfarande sätter krav på hur ni genomför projektet och vad som behövs göras utöver att skriva projektet.

Det ska finnas en makefil som användas för att kompilera projektet

För att kompilera och starta spelet ska det gå att skriva make run i terminalen.

Det ska gå att kompilera och köra projektet i SU-salarna

Det är viktigt att projektet går att kompilera (m.h.a. make) samt köra (m.h.a. make run) på systemen i SU-salarna. Detta av flera skäl:

  • Projektet ska fungera under redovisningen
  • Kodgranskning och bedömningen sker på samma system
  • Universitetet tillhandahåller en färdig installation av SFML och andra viktiga beroenden, vilket betyder att ni då kan lägga tid på det viktiga (d.v.s. programmeringen)
  • Att jobba mot specifika begränsningar är en viktig färdighet att ta med sig ut i arbetslivet!

Med detta sagt så är det ju självklart OK om ni vill utveckla på andra system också (t.ex. din egna dator), men det är då viktigt att ni kontinuerligt ser till att projektet fortfarande fungerar som väntat på systemen i SU-salarna.

Notera också att handledarna inte kan hjälpa till med problem på andra system än just SU-salarna så om ni har problem på era egna system så kan inte handledarna garanterat hjälpa till med det.

Ett gruppkontrakt ska skrivas av gruppen

Detta gruppkontrakt ska skrivas för att främja att alla gruppmedlemmar bidrar till projektet utan att lämna de andra gruppmedlemmarna i sticket.

Projektidén ska presenteras för handledare

Innan ni påbörjar arbetet med projektbeskrivningen måste ni prata med en assistent om huruvida er idé är tillräcklig för att uppfylla målen. Var beredda på att lite löst beskriva för handledaren hur ni tror att idén kan uppfylla alla krav som listas här.

En kort projektbeskrivning ska lämnas in

En kortfattad beskrivning av ert tänkta projekt ska lämnas in innan ni börjar utveckla projektet. Här ska ni beskriver vad projektet är och de olika delarna som ska ingå i just ert projekt. När ni lämnar in denna beskrivning ska ni också lämna in ett klassdiagram (se nedan).

Innan projektet utvecklas ska ett klassdiagram produceras

Detta klassdiagram ska vara en skiss över den objektorienterade designen, men behöver inte stämma helt överens med hur slutprodukten blev. Det är OK att vissa detaljer saknas, det viktiga är att man kan läsa ut att de objektorienterade kraven uppfylls.

Projektet ska versionshanteras med Git av alla gruppmedlemmar

Det är viktigt att alla gruppmedlemmar bidrar ungefär lika mycket till projektets kod och utveckling. För att kontrollera detta kommer det ske en examination i slutet av varje vecka där handledarna kontrollerar att alla har gett meningsfulla bidrag till projektets kod.

Notera: att ladda upp bilder, textfiler eller andra resurser räknas inte som ett bidrag till koden.

Gruppen ska ha haft minst ett handledaremöte

Innan projektet redovisas ska gruppen ha haft minst ett möte med sin handledare.

Projektredovisning

Den 21/5 finns det i schemat ett redovisningspass. Under detta pass kommer alla projektgrupper och lärare samlas i SU-salarna för att ha en "konferans". Tanken är att ni ska sätta upp ert projekt vid en dator så att andra kan testa det. Handledarna kommer gå runt till sina grupper, en i taget för att ta redovisning. Under tiden ni vänta kan ni gå runt och testa de andra spelen/projekten som har gjorts i kursen.

När det väl är er tur att redovisa kommer handledaren göra följande:

  • Ta närvaro av hela gruppen,
  • Testa projektet och ge uppmuntrande kommentarer,
  • Ställa ett antal frågor till gruppen i helhet,
  • Be varje medlem svara på en individuell fråga.

Så fort denna redovisning är klar så har ni nu möjlighet att finputsa projektet lite innan inlämning (se nedan).

Kodinlämning samt kodgranskning

Efter redovisningen ska ni lämna in koden för granskning (senast 24/5, 08:00). Detta gör ni genom att göra en commit i git som heter "Kodinlämning". Det är detta tillstånd av koden som kodgranskningen utgår ifrån, eventuella commits som tillkommer efter det kommer i största möjliga mån ignoreras.

Under kodgranskningen kontrollerar handledaren att alla mål har uppfyllts samt att den objektorienterade designen är rimlig. Dessutom kommer handledaren göra en övergripande kontroll över att alla gruppmedlemmar har bidragit ungefär lika mycket till projektets kodbas.

Om alla mål inte är uppfyllda eller om det finns någon person i gruppen som behöver ta igen lite arbete så finns möjlighet för komplettering, om detta blir aktuellt får ni information om detta i samband med kodgranskningen av er handledare.


Sidansvarig: Malte Nilsson
Senast uppdaterad: 2024-04-18