L3. En App

Uppgiftsbeskrivning

Deadline: 20/10 kl 08.15

Använd er utav Github för L2 och L3. Vi använder GitHub eftersom det är standardverktyget för öppen källkod och versionshantering. Det gör det lättare för andra studenter (och läraren) att följa din utvecklingsprocess, återanvända din kod och lämna feedback.

Applikationen ska driftsättas publikt på internet så att både lärare och medstudenter enkelt kan komma åt den. Det räcker alltså inte att den fungerar lokalt på din dator, utan den ska vara tillgänglig via en publik webbadress. Utgå gärna från samma tillvägagångssätt som användes i kursen 1dv613.

Syfte

  • Skriva kod som bygger på modul-koden från laboration 2. Projekten är separerade så att app-koden i laboration 3 inte påverkar modulen.
  • Skriva kod för en App med gränssnitt som uppfyller en kravspecifikation som ni själva skapar. Denna kod skall bygga på det ni lär er på föreläsningar och på boken.
  • Förbättra koden från laboration 2 enligt Clean Code och Workshop 2
  • Reflektera över och arbeta med Clean Code kapitel 2-11

En app

I laborationen kommer ni använda er modul från laboration 2 för att skriva en app. Appen skall ha en eller flera slutanvändare som använder den genom ett interface. Interfacet kan vara webbapp, fristående applikation, mobilapplikation, eller en konsol. En viktig skillnad från modulen är att en app har ett syfte som uttrycks i krav. En användare får något behov uppfyllt av appen. Behovet beskrivs som vision och krav (se 1dv613).

Till slut så skall ni ha tre olika delar i ert projekt. De tre delarna skall hanteras som individuella projekt och beroendena mellan dem skall vara som följer.

L3 Design

  1. Er modul (L2M)
  2. Era tester för er modul (L2T), Den har ett beroende till er modul (L2M). Detta betyder att kod i biblioteket anropar modulens gränssnitt (ex metoder, api eller funktioner). Men modulen ska fungera även om all kod i testerna försvinner.
  3. Er app (L3A) beror på er modul (L2M). Appen fungerar INTE utan modulen men modulen skall fungera utan appen.
  4. Era tester(L2T) och er app(L3A) skall vara oberoende. Er app skall fungera utan testerna.
  5. Er modul eller era tester får inte ha ett beroende TILL appen. Men appen skall ha ett beroende TILL modulen.

Regler

  • Skriv all kod själv, skriv inte tillsammans med någon (sida vid sida-programmering).
  • Kopiera inte kod från någon annan. Skriv inte av kod.
  • Generera inte kod (Exempelvis med LLM)
  • Ni skall använda er modul från laboration 2. Eftersom det repository ni har modulen i är under rättning för laboration 2, behöver ni skapa en ny branch så att ni kan göra ändringar i modul-koden under denna laboration utan att påverka rättningen.
  • Skriv 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 (ex. nodejs “server.listen(port…” )). Inga metoder i dina klasser får vara statiska mer än om det behövs för att starta upp koden eller om du behöver speciella namngivna konstruktorer (se Clean Code). Försök hålla så många av klasserna, attributen och metoderna som möjligt privata (se Clean Code).
  • Projekten dokumenteras på lämpligt sätt via git. Fundera över hur de olika målgrupperna (Slutanvändare, Apputvecklare, Modulanvändare, Modulutvecklare, Examinator) separat får sina informationsmål uppfyllda av er dokumentation. Fokus på effektiv dokumentation. Om ni inte tillför information och dokumentationen “känns tråkig”, fundera på om ni gör ett värdefullt bidrag eller ej.

Validering och verifiering

Fundera ut vilka testfall som behövs för att täcka in de olika kraven för er App. Skapa en tabell med testfall som alla har beskrivande namn, indata samt förväntat utfall. Ni får testa automatiskt eller manuellt men enklast är ofta att testa appen manuellt via dess gränssnitt. Minst ett test per krav (Se 1dv613 för instruktioner att skriva tester)

Kodkvalitetskrav för betyg A-E

Gå igenom all kod inklusive kod från laboration 2 (OBS!: Separat branch från den ni lämnat in i laboration 2) och uppdatera enligt bokens clean code kapitel 2-11 och det vi diskuterat på föreläsningar och workshops. Skriv en kort (4-6 meningar) reflektion för varje kapitel om hur just det kapitlet har påverkat eller inte påverkat din kod. Använd bokens termer. Ge exempel med läsbara screenshots från er kod till varje reflektion. Dokumentera detta till mig i ett separat dokument reflection.md där jag är mottagaren.

Fokusera på tydlighet, variation, ärlighet och vad som är intressant. Exempelvis om du har icke självklara överväganden med olika kvalitetsregler som står i konflikt med varandra så är dessa extra intressanta.

Jag kommer även titta på och bedöma er kod. Den skall därför i största mån vara skriven för att kunna fortsätta utvecklas av andra programmerare.

Betyg sätts efter:

  • 20%, funktionalitet, hur väl ni uppfyller kraven samt hur omfattande och komplex funktionaliteten är.
  • 25%, projektens framställning, hur väl ni presenterar projekten via dess artefakter, ex README.md
  • 10%, testning, hur väl ni testat kraven
  • 20%, reflektion, hur väl ni kan diskutera bokens innehåll
  • 25%, kodkvalitet, hur väl jag kan förstå er kod utifrån Clean Code och föreläsningar