IT1901/gr2141/docs/Report2.md

Rapport for gruppeinnlevering 2

Medlemmer: Hallvard Henriksen, Hanne Fyrand, Øystein Tveit og Øystein Martinussen.

Gruppe 41 er enige med at vi har kommet godt i gang med prosjektet. Alle i gruppen har blitt bedre kjent med GitLab mtp issues og branches. For å komme igang med gruppeinnlevering 2 gikk vi gjennom arbeidsoppgavene som måtte gjøres og fordelte de innad i gruppen.

Status

Hallvard og Øystein T delte inn kodeprosjektet vårt, Flashy, inn i flere moduler for å gjøre avhengigheten til andre moduler både relevant og hensiktsmessig. Øystein M og Hanne tok seg av å skille kjernelogikken og UI-en fra hverandre. Det har blitt opprettet flere kontroller-klasser og FXML-filer for å organisere prosjektet på en bedre måte. I tillegg ble det lagd kommunikasjon mellom kontrollerne for at alt skulle fungere som det gjorde originalt og de tre lagene (domenet, ui og persistens) spiller godt sammen.

Etter en liten diskusjon i gruppen bestemte vi oss for at implisitt lagring er det som passer best for appen vår. Ved "implisitt" mener vi her at brukeren ikke må trykke på noe for å lagre forandinger. Ved å velge denne typen lagring føler vi at appen våres gir en bedre flyt og vil føre til fornøyde brukere.

I utgangspunktet planla vi å sette test klassene for controlleren i en egen mappe kalt integrationtests, utenfor fxui. Men dette viste seg å lage mye kluss med modulene, i stedet ble testene flyttet til fxui/.../test.

Vi har valgt å definere formatet for brukerdata som vist nedenfor. Vi føler dette er en naturlig måte å strukturere JSON objektet, der hver JSON fil er en kortstokk. Kortene har videre blitt delt opp i foran/bak, fordi man vil som regel hente en av gangen.

Eksempel på JSON-fil	Objekt-typer definert hver for seg
{ "flashcards": [ { "front": { "lines": ["Hello"] }, "back": { "lines": ["There"] } } ] }	CardContent: { lines: [String] } Flashcard: { front: CardContent, back: CardContent } CardDeck: { flashcards: [Flashcard] }

All annen data, som instillinger og lignende, ligger lagret gjennom Preferences-rammeverket.

Henholdsvis har readme filene blitt oppdatert, samt har brukerhistoriene blitt utbedret. I tillegg har vi skrevet et plant UML diagram som viser en generell sammenheng mellom komponentene.

Kodekvalitet

Testene vi har skrevet dekker en god del av prosjektet våres foreløpig. Vi har implementert Jacoco for testdekningsgrad og CheckStyle samt PMD for kodekvalitet. Alle på gruppen har vært aktive deltakere for å skrive testene til modulene. For tilnærming til de ulike verktøyene har vi først skrevet koden sammen og til slutt gått over hva de ulike verktøyene har gitt oss tilbakemelding på og fikset litt av det innad i kodebasen. Det å bli kjent med nye testverktøy viste seg å være litt utfordrende i starten, men gikk bedre etterhvert.

Grunnlag for List over Collection i appen vår

Flere steder i appen bruker vi List uten at det tilsynelatende er noen god grunn for ikke å bruke Collection. Grunnen til at vi bruker List på de fleste stedene er at vi ønsker å beholde rekkefølgen på innholdet. Dette gjelder hovedsakelig bare for datamodellene i core.models.

Refleksjon

Gjennom arbeidsfasen har hver enkelt oppgave blitt laget som en issue. Dermed har vi laget en branch for hvert issue for å samle alt arbeidet knyttet til oppgaven. Ved denne gjennomføring forsikrer vi at koden som blir merget inn i master blir dobbeltsjekket av flere på gruppen og at master branchen fungerer til enhver tid. Til slutt er også alle issues koplet opp i mot milepælen til innleveringen.

Arbeidsvanene er ganske likt som det var til forrige innlevering. Vi møtes på skolen fysisk 1-2 ganger i uken og jobber sammen med prosjektet. LiveShare er det vi bruker mest og vi føler dette er et godt virkemiddel for å inkludere alle i prosessen for å utvikle appen. En annen metode vi har prøvd er å koble en PC opp til en større skjerm for at alle kan se og diskutere koden når vi programmerer. Denne metoden vil vi prøve å få til flere ganger fordi alle synes det var en fin måte å jobbe sammen på. Vi har dermed prøvd ulike metoder for å jobbe sammen som nevnt over og vil fortsette å gjøre dette fremover. Det kan godt hende at vi eventuelt prøver andre arbeidsmetoder fremover.

Noe som også er verd å merke med LiveShare, er at noen commits ender opp uten referanse til hvem som har skrevet hva. Derfor stemmer ikke alltid commit authors og contributing-feltene i Gitlab.

En mer detaljert beskrivelse av hvordan Flashy er bygd kan leses mer om i indre README.

Brukerhistorier kan også finnes her