Laboration 3 – Skriv en applikation med din och en annan students modul

🗓️Deadline:Onsdag 21 oktober 2026 kl. 17.00

Välkommen till laboration 3! Här ska du bygga en helt ny applikation, riktad till applikationens användare snarare än till andra programmerare, baserad på din modul från Laboration 2. Samtidigt ska du förbättra modulens kod utifrån principerna för Clean Code och den återkoppling du fick under Workshop 2. Applikationens kod och testrapport ska publiceras på GitHub. Precis som tidigare lämnar du in via en Merge Request i ditt privata GitLab-repo, där även dina reflektioner över kursens Clean Code-ämnen ska finnas (se Redovisning för detaljer).

Syfte

• Skriva kod för en applikation med ett gränssnitt som uppfyller din egen kravspecifikation.
• Integrera din modul från laboration 2 i applikationen, med projekten strikt separerade så att applikationens kod inte påverkar modulen.
• Integrera en annan students modul från laboration 2, även här med helt separerade projekt.
• Förbättra koden från laboration 2 utifrån principerna för Clean Code och återkopplingen från workshop 2.
• Reflektera över och tillämpa de Clean Code-ämnen som tagits upp under kursens föreläsningar, samt bokens kapitel om klasser och system.

En applikation

I den här laborationen använder du din modul från laboration 2 för att bygga en applikation. Applikationens användare – en eller flera – interagerar med den via ett gränssnitt, till exempel en webbapplikation, en fristående skrivbordsapplikation, en mobilapplikation eller en konsolapplikation. En viktig skillnad mot modulen är att en applikation har ett tydligt syfte som definieras i en kravspecifikation. Det innebär att applikationen ska uppfylla ett specifikt behov hos användaren. Du ska beskriva detta behov i form av en kort vision samt en kravlista, vilka placeras i applikationens README.md på GitHub. Dessa krav ligger sedan till grund för din testning (se Validering och verifiering nedan).

Applikationen ska tillgängliggöras så att både kursledningen och andra studenter enkelt kan testa den. Hur detta görs beror på vilken typ av applikation du bygger. Om du utvecklar en webbapplikation ska den vara driftsatt och nåbar via en webbadress. Väljer du i stället en annan typ av applikation (till exempel en konsol- eller mobilapplikation) ska den vara tillgänglig så att den går att ladda ner, installera och köra utifrån tydliga instruktioner i din README.md. Det räcker alltså inte att applikationen bara fungerar lokalt på din egen utvecklardator.

Fyra separata delar

Din applikation ingår i ett system med fyra delar som hanteras som separata projekt. Beroendena mellan dessa illustreras i figur 1.

Figur 1. Både testapplikationen från laboration 2 och applikationen från denna laboration använder din modul. Applikationen använder dessutom en annan students modul. Ingen av modulerna har beroenden till applikationen eller testerna.

1. Modulen (L2M) från laboration 2.
2. Testapplikationen eller testerna (L2T) för modulen. Dessa anropar modulens gränssnitt (exempelvis klasser och metoder), men modulen ska fungera oberoende av testerna.
3. Applikationen (L3A) som du skriver i denna laboration. Applikationen är beroende av modulen för att fungera, men modulen ska fungera helt utan applikationen.
4. En annan students modul (L3M) som du integrerar i din applikation. Applikationen är beroende av denna modul för att fungera, men modulen ska fungera utan din applikation. Denna modul behöver inte ha en central roll, och din insats bedöms inte utifrån dess funktionalitet.

Detta innebär att:

• Applikationen och testerna är helt oberoende av varandra – applikationen ska fungera utan testerna.
• Varken modulerna eller deras tillhörande tester får ha några beroenden till applikationen.

Applikationens kod ska ligga i ett eget, publikt repo på GitHub, helt separat från modulernas repon.

Hur du kopplar in modulerna i applikationen beror på hur de är tillgängliggjorda – till exempel som ett installerbart paket, som ett beroende direkt från GitHub, eller genom att du kopierar in modulens källkod. Kopierar du in källkoden, lägg den i en egen katalog och gör inga ändringar i den där, så att modulen förblir ett separat projekt. Ändringar i din egen modul gör du i modulens repo.

Fortsätt arbeta med modulen från laboration 2

Modulens repository på GitHub ligger till grund för bedömningen av laboration 2. För att du ska kunna vidareutveckla modulen under den här laborationen utan att störa bedömningen, måste du först skapa en tagg med namnet laboration-2 och pusha den till GitHub. Bedömningen av laboration 2 utgår helt från denna tagg, och kursledningen kontrollerar att den pekar på en commit från före deadline för laboration 2 (onsdag 2026-09-30 kl. 17.00). Därefter kan du fortsätta arbeta på grenen main som vanligt.

Gör så här för att skapa och pusha taggen, oavsett om du har gjort nya commits efter deadline för laboration 2 eller inte:

1. Ta fram den sista commiten du gjorde före deadline för laboration 2:

   git log --oneline --before="2026-09-30 17:00" -1

2. Kopiera commitens ID (de första tecknen på raden, t.ex. a1b2c3d), och skapa och pusha taggen på just den commiten:

   git tag laboration-2 a1b2c3d
   git push origin laboration-2

När du ändrar modulen ska du även justera testerna (L2T) så att de fortsätter att fungera och täcker modulens nuvarande beteende.

Tänk på att det kan vara en eller flera studenter som använder din modul i sina applikationer. Därför ska du inte göra ändringar i modulens gränssnitt (till exempel klasser och metoder) som bryter bakåtkompatibiliteten. Du kan däremot lägga till nya klasser och metoder, och du kan ändra i modulens interna kod.

Vill du förbättra ett publikt namn eller en metodsignatur, inför den nya varianten och behåll den gamla vid sidan av den. Låt den gamla delegera till den nya, och markera den som föråldrad (eng. deprecated) – i JavaScript till exempel med JSDoc-taggen @deprecated, i Java med annotationen @Deprecated. Hur du har hanterat sådana avvägningar mellan bakåtkompatibilitet och Clean Code är ett bra underlag för dina reflektioner.

Den andra modulen

Du ska använda en annan students modul i din applikation. Välj en modul från listan som anslås i kursens kanal på Zulip, och välj en som är skriven i samma programmeringsspråk som din applikation. Kom ihåg att det är din egen modul som ska ha huvudrollen i applikationen. Du kan till exempel använda den andra studentens modul som ett komplement, eller som en del av en funktion som du implementerar i applikationen.

Du tar inte ansvar för den andra modulen på något sätt. Stöter du på brister i den påverkar de inte bedömningen av din inlämning, förutsatt att du dokumenterar dem – till exempel i TEST_REPORT.md eller som ett ärende (eng. issue) i modulens GitHub-repo. Eventuella problem kan på lämpligt sätt kommuniceras till den som är ansvarig för modulen.

Validering och verifiering

Ta fram de testfall som krävs för att täcka in applikationens krav – det ska finnas minst ett testfall per krav. Du kan välja att testa automatiskt eller manuellt, men det är ofta smidigast att testa applikationen manuellt via dess gränssnitt.

Testningen ska redovisas i en testrapport med filnamnet TEST_REPORT.md, placerad i roten av applikationens GitHub-repo. En mall för rapporten finns i ditt laboration-3-repo på GitLab (se Redovisning). Skapa en tabell i Markdown-format där varje rad representerar ett testfall och innehåller följande information:

1. Ett beskrivande namn på testfallet
2. Vilket krav som testas
3. Indata
4. Förväntat utfall
5. Faktiskt utfall

Skriv även en kort sammanfattning av hur applikationen har testats. Sammanfattningen ska vara tillräckligt tydlig för att en annan person ska kunna utföra samma test.

Kodkvalitetskrav

Gå igenom all din kod – inklusive modulens kod från laboration 2 – och förbättra den utifrån ämnena i Reflektion nedan samt det som har tagits upp under workshops.

Kursledningen kommer att bedöma din kod. Den ska därför i största möjliga utsträckning vara skriven och strukturerad så att andra utvecklare enkelt kan förstå den och fortsätta bygga vidare på den.

Reflektion

För varje ämne nedan ska du skriva en kort reflektion (cirka 4–6 meningar) om hur principerna har – eller inte har – påverkat din kod. Använd bokens terminologi och illustrera varje reflektion med konkreta exempel från din egen kod, gärna i form av kodblock. Reflektionerna ska skrivas i filen REFLECTION.md med kursledningen som primär mottagare.

Totalt är det tio reflektioner, en per ämne. Läsanvisningarna med kapitelhänvisningar för båda upplagorna av Clean Code finns på respektive föreläsningssida.

Ämne	Underlag
Meningsfulla namn	Föreläsning 1
Funktioner	Föreläsning 2
Kommentarer	Föreläsning 3
Formatering	Föreläsning 4
Objekt och datastrukturer	Föreläsning 5
Felhantering	Föreläsning 5
Gränser (eng. boundaries)	Föreläsning 5
Enhetstester	Föreläsning 5
Klasser	Kapitel 10 i förstautgåvan (2:a upplagan: kapitel 13)
System	Kapitel 11 i förstautgåvan (2:a upplagan: kursledningen återkommer)

Fokusera på tydlighet, variation och ärlighet. Lyft fram det som är mest intressant i din utvecklingsprocess. Om du exempelvis har tvingats göra avvägningar mellan kvalitetsregler som står i konflikt med varandra är detta extra värdefullt att diskutera. Det är mer meriterande att du identifierar och reflekterar över dina egna brister än att du försöker dölja dem.

Utöver de tio reflektionerna ska du i REFLECTION.md även redovisa hur ett eventuellt AI-samarbete har sett ut (se Regler).

Dokumentation

Fundera över hur de olika målgrupperna – applikationens användare, applikationsutvecklare, modulanvändare, modulutvecklare och examinator – var för sig får sina informationsbehov uppfyllda av din dokumentation, samt i vilket repo informationen hör hemma (applikationens repo, modulens repo eller i REFLECTION.md). Fokusera på effektiv dokumentation: om den inte tillför något värde eller känns överflödig bör du fundera på om den verkligen bidrar till projektet.

Checklista

Du vet att du är klar när du har:

• Byggt en applikation som använder din modul och en annan students modul, med en vision och tillhörande krav beskrivna i din README.md.
• Tillgängliggjort applikationen så att den enkelt går att nå eller köra för den som ska testa den.
• Hållit modulerna, testerna och applikationen separerade som fristående projekt enligt figur 1.
• Taggat modulens L2-version med laboration-2 och därefter fortsatt att förbättra modulens kod, och justerat dess tester, på grenen main.
• Testat varje krav och redovisat resultatet i TEST_REPORT.md i applikationens GitHub-repo.
• Skrivit en reflektion per ämne samt redovisat ditt eventuella AI-samarbete i REFLECTION.md.
• Pushat applikationen till ett publikt GitHub-repo med en commit-historik som tydligt visar din arbetsprocess över tid.
• Skapat en Merge Request (MR) i ditt laboration-3-repo på GitLab, och i beskrivningen inkluderat länkar till applikationens och din moduls GitHub-repon och till den andra studentens modul, samt hur applikationen nås eller körs.

Redovisning

Se Verktyg och plattformar för en genomgång av GitLab, GitHub och Zulip och hur de används i kursen.

Applikationens kod och testrapport (TEST_REPORT.md) ska vara publika på GitHub, precis som modulen. Reflektionerna (REFLECTION.md) lämnar du däremot in på samma sätt som tidigare, via en Merge Request i ditt privata laboration-3-repo på GitLab.

Redovisningen sker i fyra steg innan deadline:

1. Koda, committa och pusha till GitHub. Skriv din applikation och versionshantera den med Git mot ett publikt repo på GitHub. Flytta mallen för TEST_REPORT.md från ditt GitLab-repo till roten av applikationens GitHub-repo, komplettera den där (se Validering och verifiering) och committa den tillsammans med koden. Pusha även förbättringarna av din modul till modulens GitHub-repo, efter att du taggat L2-versionen (se Fortsätt arbeta med modulen från laboration 2). Se till att historiken visar ditt arbete över tid (räkna med minst daglig commit).

2. Tillgängliggör applikationen. En webbapplikation ska vara nåbar via en webbadress. Andra typer av applikationer ska gå att ladda ner, installera och köra utifrån instruktionerna i README.md. Se till att den version som går att nå eller ladda ner motsvarar koden på GitHub.

3. Skriv REFLECTION.md. Komplettera och committa filen i rotkatalogen på main i ditt laboration-3-repo på GitLab. Den innehåller samtliga tio reflektioner och redovisningen av ditt eventuella AI-samarbete.

4. Skapa en MR. Skapa en MR från main till lnu/submit i ditt laboration-3-repo på GitLab. MR-beskrivningen förifylls med en inlämningsrapport. Fyll i den med länkar till applikationens och din moduls GitHub-repon och till den andra studentens modul, samt hur applikationen nås eller körs. Det är via MR:en som kursledningen granskar och bedömer din inlämning.

Detta krävs innan deadline

Har du inte skapat en MR innan deadline räknas uppgiften inte som inlämnad. Om MR:en är ofullständig påverkar det bedömningen enligt betygskriterierna nedan. Det gäller till exempel om länkarna eller REFLECTION.md saknas eller är ofullständiga, om applikationen inte går att nå eller köra, eller om TEST_REPORT.md saknas eller är ofullständig i applikationens GitHub-repo.

Bedömning

Kursledningen bedömer din inlämning via din MR, utifrån hur väl du uppfyller kraven ovan samt kodkvalitet. Se Betygskriterier för poängskalan och hur laborationsbetyget vägs in i slutbetyget.

Bedömningen vägs samman av fem områden:

Område	Vikt	Vad som bedöms
Funktionalitet	20 %	Hur väl applikationen uppfyller kraven, och hur omfattande och komplex funktionaliteten är.
Framställning	25 %	Hur väl projekten presenteras via sina artefakter, t.ex. README.md.
Testning	10 %	Hur väl kraven är testade.
Reflektion	20 %	Hur väl du kan diskutera bokens innehåll.
Kodkvalitet	25 %	Hur väl kursledningen kan förstå din kod utifrån Clean Code och föreläsningarna.

För godkänd nivå “E”

• Applikationen fungerar, använder din modul och uppfyller de viktigaste kraven. Den är tillgängliggjord och går att nå eller köra.
• Modulerna, testerna och applikationen är separerade och beroendena följer figur 1.
• Vision och krav finns beskrivna, och varje krav har minst ett testfall i en testrapport. De flesta testfall ska fungera – något enstaka testfall får misslyckas eller en känd bugg får finnas.
• Det finns en läsbar dokumentation på GitHub för både applikationen och modulen.
• All kod finns med historik på GitHub (räkna med minst daglig commit).
• Koden är genomgången och förbättrad utifrån kursboken.
• Det finns en reflektion per ämne, baserad på kursboken och med exempel från din egen kod.
• Du uppfyller reglerna nedan.

För högre betyg “A–D”

• Samtliga punkter för godkänd nivå.
• Applikationens funktionalitet är omfattande och komplex, och samtliga krav fungerar.
• Testningen är övertygande och noggrann.
• Det är mycket tydligt utifrån repona hur applikationen används och hur modulen återanvänds – varje målgrupp får sina informationsbehov uppfyllda.
• Koden är genomgående lätt att förstå och att vidareutveckla för andra programmerare.
• Reflektionerna är varierade och ärliga, använder bokens termer och visar avvägningar mellan kvalitetsregler – inte bara att reglerna följts.

Regler

• Allt du lämnar in ska du fullt ut förstå och kunna förklara – även de delar som tagits fram tillsammans med AI-assistenter (t.ex. ChatGPT, GitHub Copilot eller Claude). Sådant samarbete är tillåtet, men ska redovisas kort i REFLECTION.md (se Akademisk integritet för kursens fullständiga AI-policy).
• Laborationen är individuell – programmera inte tillsammans med någon annan person (t.ex. parprogrammering).
• Committa och pusha kontinuerligt under arbetets gång, så att din utvecklingsprocess går att följa på GitHub.
• Kopiera inte kod från någon annan. Skriv inte av kod. Undantaget är koden i din egen och den andra studentens modul, som du får använda på det sätt modulen är tillgängliggjord (se Fyra separata delar).
• Du ska använda din egen modul från laboration 2 och en annan students modul från listan på Zulip.
• Fokusera på objektorienterad kod med klasser och metoder i klasser. Du kan ha kod utanför klasser, men bara om den behövs för att starta upp koden (t.ex. Node.js server.listen(port…)). Inga metoder i dina klasser bör vara statiska, mer än om det behövs för att starta upp koden eller om du behöver namngivna konstruktorer (se Clean Code). Försök hålla så många klasser, attribut och metoder som möjligt privata.