Göm meny

Temarapport 3

I Temarapport 3 ska ni dels beskriva hur ni valt att designa er lösning på temauppgift 3, granska och analysera er modell, samt beskriva de algoritmer för crossover och mutation ni tagit fram.

(Uppdaterad för VT18)

Lärandemål för Temarapport 3

Att presentera den struktur och uppdelning av ens kod är en viktig färdighet för att kunna kommunicera den till andra. För algoritmer har ni provat göra detta med hjälp av beskrivning i punktform i Tema 2. I Tema 3 ska ni öva på att beskriva er objektorienterade kod med hjälp av klassdiagram, men även precis som förut beskriva era algoritmer i punktform.

I temauppgiften har ni fått beskriva satser längre på mer än två rader med en kommentar, och dessa kan t.ex. vara en utgångspunkt för era algoritmbeskrivningar.

Temarapporten

Den struktur som är angiven i avnittet “Rapportdisposition” ska följas oavsett den nivå man siktar på. Fullständiga beskrivningar av rapportinnehållet finns för nivåerna Brons, Silver och Guld. Om ni satsar på t.ex. Silver behöver ni endast läsa beskrivningen för Silver nedan (dvs ni behöver inte läsa både den för Brons och Silver).

Brons

  • Problemuppdelning
    • Klassdiagram i UML ska finns för alla klasser ni själva antingen skapat från grunden eller jobbat vidare på (dvs BreedingFacility och er DNA-klass för alla, samt eventuella klasser som ni skapat utöver dessa).
  • Algoritmbeskrivningar:
    • Beskriv i punktform av er implementation algoritmerna för 1) crossover, 2) mutation och 3) skapandet av första generationen instanser av er DNA-klass. Beskrivningen i punktform ska vara beskriven på den nivån att läsaren ska förstå principerna utan att kunna programmera just programmeringsspråket Python.
    • Beskriv i löpande text under varje algoritms punktformsbeskrivning vilka metoder som utgör er implementation av algoritmen, samt hur se interagerar med varandra. T.ex. “Crossoveralgoritmen börjar med ett anrop till metoden X i klassen Y från metoden P i klassen Q”.
  • Diskussion
    • Diskutera namngivningen av era klasser, instansvariabler och metodnamn. Följer de ett mönster? Om ja, vilket? Om nej, vad skulle ni kunna ändra på för att förbättra detta? Upplevde ni namngivningen som problematisk? Vad i så fall och varför?

Silver

  • Problemuppdelning
    • Klassdiagram i UML ska finns för alla klasser ni själva antingen skapat från grunden eller jobbat vidare på (dvs BreedingFacility och er DNA-klass för alla, samt eventuella klasser som ni skapat utöver dessa).
    • Beskriv era klasser kort med ord. Beskrivningens syfte är att beskriva det de enskilda klasserna representerar och på vilket sätt de skiljer sig från varandra. I rapporten beskriver ni de problem ni löst; syftet med beskrivningarna av era klasser är att på en översiktsnivå koppla ihop er problembeskrivning era klasser: Vilka delar av problembeskrivningen ansvarar de olika klasserna för?
    • För varje klass, skriv en kort beskrivning av vad de olika metoderna gör. Specifika detaljer kring hur metoden gör det den gör behöver inte skrivas. Det viktiga är hur ni formulerar vad den gör, dvs vad är effekten av att metoden körs? Ändras något i instansen? Returneras något?
    • För varje klass, skriv en kort beskrivning av dess instansvariabler. Beskrivningarna ska förklara den innehåller (vilken datatyp), samt hur och i vilka sammanhang den används. T.ex. “instansvariabeln data_points är en lista av heltal som lagrar varje enskilt mätvärde i en mätserie. Den används som rådata när snitt, max- och minvärde ska beräknas.”.
  • Algoritmbeskrivningar:
    • Beskriv i punktform av er implementation algoritmerna för 1) crossover, 2) mutation och 3) skapandet av första generationen instanser av er DNA-klass. Beskrivningen i punktform ska vara beskriven på den nivån att läsaren ska förstå principerna utan att kunna programmera just programmeringsspråket Python.
    • Beskriv i löpande text under varje algoritms punktformsbeskrivning vilka metoder som utgör er implementation av algoritmen, samt hur se interagerar med varandra. T.ex. “Crossoveralgoritmen börjar med ett anrop till metoden X i klassen Y från metoden P i klassen Q”.
  • Diskussion
    • Diskutera namngivningen av era klasser, instansvariabler och metodnamn. Följer de ett mönster? Om ja, vilket? Om nej, vad skulle ni kunna ändra på för att förbättra detta? Upplevde ni namngivningen som problematisk? Vad i så fall och varför?

Guld

  • Problemuppdelning
    • Klassdiagram i UML ska finns för alla klasser ni själva antingen skapat från grunden eller jobbat vidare på (dvs BreedingFacility och er DNA-klass för alla, samt eventuella klasser som ni skapat utöver dessa).
    • Beskriv era klasser kort med ord. Beskrivningens syfte är att beskriva det de enskilda klasserna representerar och på vilket sätt de skiljer sig från varandra. I rapporten beskriver ni de problem ni löst; syftet med beskrivningarna av era klasser är att på en översiktsnivå koppla ihop er problembeskrivning era klasser: Vilka delar av problembeskrivningen ansvarar de olika klasserna för?
    • För varje klass, skriv en kort beskrivning av vad de olika metoderna gör. Specifika detaljer kring hur metoden gör det den gör behöver inte skrivas. Det viktiga är hur ni formulerar vad den gör, dvs vad är effekten av att metoden körs? Ändras något i instansen? Returneras något?
    • För varje klass, skriv en kort beskrivning av dess instansvariabler. Beskrivningarna ska förklara den innehåller (vilken datatyp), samt hur och i vilka sammanhang den används. T.ex. “instansvariabeln data_points är en lista av heltal som lagrar varje enskilt mätvärde i en mätserie. Den används som rådata när snitt, max- och minvärde ska beräknas.”.
  • Algoritmbeskrivningar:
    • Beskriv i punktform av er implementation algoritmerna för 1) crossover, 2) mutation och 3) skapandet av första generationen instanser av er DNA-klass. Beskrivningen i punktform ska vara beskriven på den nivån att läsaren ska förstå principerna utan att kunna programmera just programmeringsspråket Python.
    • Beskriv i löpande text under varje algoritms punktformsbeskrivning vilka metoder som utgör er implementation av algoritmen, samt hur se interagerar med varandra. T.ex. “Crossoveralgoritmen börjar med ett anrop till metoden X i klassen Y från metoden P i klassen Q”.
  • Diskussion
    • Diskutera namngivningen av era klasser, instansvariabler och metodnamn. Följer de ett mönster? Om ja, vilket? Om nej, vad skulle ni kunna ändra på för att förbättra detta? Upplevde ni namngivningen som problematisk? Vad i så fall och varför?
    • Diskutera nedanstående designval som uppstår när man programmerar objektorienterat:
      • När man skapar egna klasser som ska interagera med varandra behöver man ofta fatta beslut om vilken klass ska vara den “aktiva” och vilken klass som ska vara den “passiva”. Om vi har en klass som representerar en CSV-fil, CSVData och en klass som innehåller flera CSV-filer, CSVDataCollection. Antag att vi vill implementera funktionalitet för att ta bort en rad från CSV-datat, är ett sätt att t.ex. ha metoden delete_row(row_number) i klassen CSVData. Ett annat sätt är att ha metoden delete_row(csv_data, row_number) i klassen CSVDataCollection. Dvs antingen se det som att CSVData-instanser ges kommandot att ta bort en rad från sig själv, eller att CSVDataCollection ges i uppdrag att ta bort en rad från en CSVData-instans som den innehåller. Samma val finns för de algoritmer som ni implementerat i Temauppgift 3: t.ex. är crossover något som en BreedingFacility-instans gör med två instanser av er DNA-klass, eller är det så att en instans av DNA-klassen “parar” sig med en annan instans av DNA-klassen? Är mutation något som görs av BreedingFacility på ett DNA-objekt, eller något ett DNA-objekt gör på sig själv?
      • Vad kan man tänka sig för för- och nackdelar med de olika perspektiven?
      • Det viktiga med er diskussion är inte vad ni kommer fram till utan hur ni resonerar. För att få Guld bör ni kunna komma på minst en fördel och en nackdel med båda perspektiven (dvs en fördel och en nackdel med perspektiv 1 och en fördel och en nackdel med perspektiv 2) som ni beskriver på ett relativt konkret sätt. Beskrivningen “Genom att lägga metoden i X kan man göra sitt program mer resurseffektivt/bättre/mer i linje med tanken bakom objektorientering eftersom man kan anropa den från instanser av Y” är på inga sätt konkret. Här saknas en beskrivning av på vilket sätt som det blir mer resurseffektivt/bättre/mer i linje med tanken bakom objektorientering.

Rapportdisposition

OBS! Alla delar av rapportdispositionen ska finnas med i rapporten.

Se till att nedanstående information finns med:

  • namn på gruppmedlemmar i början av rapporten
  • vilken variant ni löste i temauppgiften
  • vilken nivå ni siktar på (Brons, Silver, Guld

Det är fritt fram att skapa underrubriker till de som beskrivs nedan om det bidrar till att strukturera rapporten.

Rubrik: Problembeskrivning

Börja med en övergripande beskrivning av vilka problem och delproblem som ni löser i uppgiften med egna ord. Ni får använda figurer om ni vill.

Syftet med att beskriva problemet är benämna och förklara alla begrepp ni kommer använda er av i era algoritmer (ungefär som att en beskrivning av sorteringsproblemet från Quick Sorts perspektiv behöver beskriva pivot value, left mark och right mark)

Rubrik: Problemuppdelning

Under rubriken problemuppdelning beskriver ni era klasser med ett klassdiagram och för vissa nivåer text. Se nivåbeskrivningarna ovan.

I klassdiagrammet/beskrivningarna behöver inte metoder som börjar med __ finnas med (som t.ex. __init__ och __str__).

Rubrik: Algoritmbeskrivningar

Beskriv i punktform (utan kod) era algoritmer. Se nivåbeskrivningarna för detaljer. Se till att ni har en underrubrik för varje algoritm.

Rubrik: Diskussion

Under diskussionsrubriken diskuterar ni olika er problemuppdelning och er implementation. Vad ni ska diskutera beror på den nivå ni satsar på.


Sidansvarig: Jody Foo
Senast uppdaterad: 2018-05-08