Göm meny

Algoritmrapport 3

I algoritmrapport 3 ska ni planera och beskriva ett bok-katalogsystem, samt diskutera och analysera ert system.

Att kunna stukturera och planera system och projekt är en väsentlig färdighet när man skall programmera någonting som innehåller mer än bara några få funktioner. I denna rapport kommer ni, utan att skriva någon kod, att planera ett system från grunden, och att beskriva det med hjälp av klassdiagram och i punktform. Ni har tidigare arbetat i isolerade delar av större system. Här är målet att ni ska få arbeta med ett helt system, som ni själva ska skapa på ett objektorienterat sätt.

Inlämning

Algoritmrapporten lämnas in via Lisam. Se Inlämningar

Ni kommer få en av bedömningarna komplettering, 1 poäng, 2 poäng eller 3 poäng på algoritmrapporten.

  • Om man får 1 eller 2 poäng vid första inlämningen får man lämna in en komplettering om man vill försöka få högre bedömning. Ta kontakt med den lärare som rättat er rapport så att hen kan låsa upp er inlämning i Lisam (genom att markera den för komplettering).
  • Om man får komplettering vid första inlämningen är det den första godkända bedömningen som gäller. Dvs. om ni vill ha 2 eller 3 poäng, se till att det ni skickar in som komplettering uppfyller kraven för detta.

Uppgift till algoritmrapport 3

I denna rapport kommer ni att planera och beskriva (inte implementera!) ett katalogsystem för böcker i ett bibliotek. Hur komplicerat systemet är beror på hur många poäng ni satsar på. Varje nivå lägger på extra funktionalitet, så de högre nivåerna ska ha med funktionalitet från alla lägre nivåer, tillsammans med det som står beskrivet för nivån:

  • 1 poäng: Systemet ska kunna katalogisera böcker. Det ska finnas information om böckerna (titel, författare m.m.), samt möjlighet att lägga till, ta bort och redigera böcker i systemet.
  • 2 poäng: Systemet ska ha möjlighet att låna ut böcker och ta emot utlånade böcker. En bok ska inte gå att låna ut flera gånger, utan att den lämnas tillbaka först.
  • 3 poäng: Systemet ska hålla reda på personer som böckerna lånas ut till. Om en bok är utlånad ska det vara möjligt att veta till vem. Samma person kan låna mer än en bok i taget.

Rapportstruktur

Algoritmrapporten lämnas i som pargrupp. Följande information ska finnas med i början av rapporten:

  • Era namn, er pargrupp, kurskod och datum
  • Namnet på uppgiften (t.ex. Algoritmrapport 1)
  • Vilken nivå som ni satsar på (1, 2 eller 3 poäng).

Komplettering ges på inlämningen om något av ovanstående saknas.

Rapportens struktur är densamma oberoende av vilken nivå man siktar på. Nedan beskrivs delarna er rapport ska ha med. Det är fritt fram att skapa underrubriker till de som beskrivs nedan om det bidrar till att strukturera rapporten.

Problemuppdelning

Problemuppdelningsavsnittet ska ha med följande:

Klassdiagram i UML ska finns för alla klasser. Detta ska innehålla alla klasser i ert system, tillsammans med metoder och instansvariabler, och hur klasserna relaterar till varandra. I klassdiagrammet/beskrivningarna behöver inte metoder som börjar med __ finnas med (som t.ex. __init__ och __str__).

Beskriv era klasser kort med ord. Beskrivningens syfte är att beskriva vad de olika 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 dess instansvariabler. Beskrivningarna ska förklara vad variabeln 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.”.

För varje klass, skriv en kort beskrivning av vad de olika metoderna gör. Det är inte nödvändigt att gå in i detalj om exakt hur metoden gör vad den gör. Beskriv bara vad den gör: om den tar in någon data som argument, vad som ändras i instansen och/eller vad som returneras.

Beskriv eventuella brister som ert system har p.g.a. dess design. Systemet ska kunna utföra dess tänkta uppgifter enligt den poäng-nivå ni siktar på , men det är acceptabelt att systemet har har funktionella begränsningar. Om systemet t.ex. inte kan skilja på böcker med identiska titlar måste ni i detta avsnitt beskriva denna begränsning, samt vad i er systemdesign som är orsaken till denna begränsning.

Ett annat exempel på en begränsning ett system skulle kunna ha är att det inte är möjligt för en person att låna fler än ett visst antal böcker p.g.a. en teknisk begränsning.

Begränsningar i vilken typ av information som lagras om böcker behöver ni inte ta upp om det inte har någon konsekvens för systemets funktionalitet (givet den nivå ni satsar på). Dvs att om ni inte lagrar hur många sidor en bok har behöver ni inte ta upp det som en begränsning här. Däremot, om det skulle vara så systemet inte kan låna ut böcker på måndagar p.g.a. att systemet inte lagrar hur många sidor en bok har, så måste ni ta upp det som en begränsning (… just denna begränsning kommer nog inget system ha dock).

Diskussion

Namngivning: 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?

Aktiv eller passiv: 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”. Vi har till exempel 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. Ett sätt är att 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 tar bort en rad från sig själv (aktiv), eller att CSVDataCollection tar bort en rad från en CSVData-instans som den innehåller (passiv).

Samma val finns för det system som ni har gjort upp. Finns t.ex. metoden för att editera en bok i boken själv eller i någon annan del av systemet? Vad kan man tänka sig för för- och nackdelar med de olika perspektiven? Varför valde ni att göra så som ni gjorde? Finns det delar av systemet som hade blivit bättre eller smidigare om ni gjort på något annat sätt? Det viktiga i er diskussion är inte vad ni kommer fram till, utan hur ni resonerar. Om ni skriver att en variant är bättre så bör ni resonera kring varför den är bättre.


Sidansvarig: Jody Foo
Senast uppdaterad: 2021-10-19