oysteikt-skolearbeid
/
TDT4100-project
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

krav

master
Oystein 2021-04-26 21:24:49 +02:00
parent 075988f327
commit fd83e1291d
2 changed files with 33 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
.gitlab/graphics/FXML-diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 163 KiB

51
REQUIREMENTS.md
View File

@ -17,17 +17,15 @@ bruke. Om dere har tatt eller tar TDT4180 - Menneske-maskin-interaksjon kan det
å bruke noen av konseptene dere har lært der (men merk at dere ikke vurderes ut i fra det i dette å bruke noen av konseptene dere har lært der (men merk at dere ikke vurderes ut i fra det i dette
faget). faget).
Dere skal også lage Controller- og App-klasser som starter appen og kobler sammen brukergrensesnitt og underliggende klasser. Merk at appen deres skal bygges etter Model-ViewController-prinsippet. Det betyr at det skal være et klart skille mellom modell (model), grensesnitt (view), og kontroller (controller) i appen. Her er grensesnittet definert av FXML-filene deres, Dere skal også lage Controller- og App-klasser som starter appen og kobler sammen brukergrensesnitt
og underliggende klasser. Merk at appen deres skal bygges etter Model-ViewController-prinsippet.
Det betyr at det skal være et klart skille mellom modell (model), grensesnitt (view), og
kontroller (controller) i appen. Her er grensesnittet definert av FXML-filene deres,
og modellene er de underliggende klassene. Kontrollerens jobb er å binde sammen grensesnitt og og modellene er de underliggende klassene. Kontrollerens jobb er å binde sammen grensesnitt og
modeller, altså å holde verdiene i grensesnittet oppdatert i forhold til modellene, og å reagere på modeller, altså å holde verdiene i grensesnittet oppdatert i forhold til modellene, og å reagere på
brukerinput i grensesnittet og kalle passende metoder i modellene. brukerinput i grensesnittet og kalle passende metoder i modellene.
``` ```
I denne delen har vi laget én Application-klasse som laster én hoved-FXML-fil + kontroller, som internt linker til flere andre fxml filer med hver sine kontrollere. Kontrollerne binder sammen sine relevante grensesnittsparametere med en global [`Model`][Model-file]-klasse og setter opp event-lyttere på de relevante FXML-elementene, i tillegg til å sette opp en eventbus mellom seg og de andre kontrollerne for kommunikasjon dem imellom. Eventbus bruker dataklasser arvet fra [`Event`][Event-file]-klassen, som beskrivelse på hvilken type melding som blir sendt. Basert på typen av meldingen skiller eventbusen hvilke funksjoner som skal fyres av. Dette er en variant av observatør-observert metoden.
Her er et diagram over koblingene i programmet:
![TODO: ADD DIAGRAM]()
### Del 2 - Filbehandling ### Del 2 - Filbehandling
@ -99,17 +97,27 @@ Controller klasser:
Brukergrensesnitt: Brukergrensesnitt:
[resources/fxml/][fxml-folder] [resources/fxml/][fxml-folder]
I denne delen har vi laget én Application-klasse som laster én hoved-FXML-fil + kontroller, som internt linker til flere andre fxml filer med hver sine kontrollere. Kontrollerne binder sammen sine relevante grensesnittsparametere med en global [`Model`][Model-file]-klasse og setter opp event-lyttere på de relevante FXML-elementene, i tillegg til å sette opp en eventbus mellom seg og de andre kontrollerne for kommunikasjon dem imellom. Eventbus bruker dataklasser arvet fra [`Event`][Event-file]-klassen, som beskrivelse på hvilken type melding som blir sendt. Basert på typen av meldingen skiller eventbusen hvilke funksjoner som skal fyres av. Dette er en variant av observatør-observert metoden.
Her er et diagram over koblingene i programmet:
<div align="center">
<img src=".gitlab/graphics/FXML-diagram.png">
</div>
2. **Minimum en av klassene må ha noe funksjonalitet utover ren datalagring, en form for kalkulasjoner (i en utvidet betydning av begrepet).** 2. **Minimum en av klassene må ha noe funksjonalitet utover ren datalagring, en form for kalkulasjoner (i en utvidet betydning av begrepet).**
Klassene som blir brukt for kalkulasjon har vi lagt i [app/service][service-folder] Klassene som blir brukt for kalkulasjon har vi lagt i [app/service][service-folder]
3. **Det skal implementeres korrekt innkapsling og validering for tilstandene til objektene i appen.** 3. **Det skal implementeres korrekt innkapsling og validering for tilstandene til objektene i appen.**
Ettersom vi bruker en eventbus, så ligger innkapslingen og valideringen for tilstandene i events og i funksjonene som tar input fra brukergrensesnittet. Eksempler på dette kan dere se her: Ettersom vi bruker en eventbus, så ligger innkapslingen og valideringen for tilstandene i events og i funksjonene som tar input fra brukergrensesnittet. I FileOperations er det lagt inn omfattende
Eksempler på dette kan dere se her:
<!-- TODO: Legg til kodelink her --> - [events/LanguageChangedEvent.java][LanguageChangedEvent-file]
<!-- TODO: Legg til kodelink her --> - [events/EditorChangedEvent.java][EditorChangedEvent-file]
<!-- TODO: Legg til kodelink her --> - [events/ThemeChangedEvent.java][ThemeChangedEvent-file]
4. **Appen skal organiseres etter Model-View-Controller prinsippet, som beskrevet ovenfor.** 4. **Appen skal organiseres etter Model-View-Controller prinsippet, som beskrevet ovenfor.**
@ -119,15 +127,18 @@ Hovedbitene med state som skal være global for hele applikasjonen ligger i en k
1. **Et grensesnitt som minimum har en metode for lesing fra og en for skriving til fil.** 1. **Et grensesnitt som minimum har en metode for lesing fra og en for skriving til fil.**
Dette finner dere i <!-- TODO: Legg til kodelink her --> Dette finner dere i [settings/SettingsProviderI.java][interface-file]
Her er metodene for lesing fra og skriving til fil som innebærer programmtilstandene.
2. **Minimum en ny klasse (altså ikke en av klassene dere har lagd tidligere i prosjketet) som implementerer grensesnittet. Klassen skal altså lagre (deler av) tilstanden til appen deres til et valgfritt format og lese inn det samme formatet til appen.** 2. **Minimum en ny klasse (altså ikke en av klassene dere har lagd tidligere i prosjketet) som implementerer grensesnittet. Klassen skal altså lagre (deler av) tilstanden til appen deres til et valgfritt format og lese inn det samme formatet til appen.**
Dette finner dere i <!-- TODO: Legg til kodelink her --> Dette finner dere i [settings/SettingsProvider.java][settings-file]
SettingsProvider-filen implementerer grensesnittet og realiserer funksjonaliteten. Her blir tilstandene til innstillingene
3. **Brukergrensesnittet i appen må utvides med mulighet for å skrive tilstanden til og lese fra fil.** 3. **Brukergrensesnittet i appen må utvides med mulighet for å skrive tilstanden til og lese fra fil.**
Dette finner dere i <!-- TODO: Legg til kodelink her --> Dette finner dere i [MenubarController.java][MenubarController-file]
### Del 3 - Feilhåndtering ### Del 3 - Feilhåndtering
@ -135,9 +146,7 @@ Dette finner dere i <!-- TODO: Legg til kodelink her -->
På lik måte som det er lagt inn innkapsling der hvor programmet får input ifra brukeren, er det er det meste av feilhåndteringen blir gjort. På lik måte som det er lagt inn innkapsling der hvor programmet får input ifra brukeren, er det er det meste av feilhåndteringen blir gjort.
I tillegg er det blitt lagt til feilhåndtering for filer I tillegg er det blitt lagt til feilhåndtering for filer.
<!-- - Om dere har en eksepsjonelt stor app, kan dere, etter avtale med studass, slippe unna med å bare feilhåndtere deler av koden. -->
### Del 4 - Testing ### Del 4 - Testing
@ -147,8 +156,6 @@ I tillegg er det blitt lagt til feilhåndtering for filer
Dere finner testene i [src/test/java/app][tests-folder] Dere finner testene i [src/test/java/app][tests-folder]
<!-- - Om dere har en eksepsjonelt stor app, kan dere, etter avtale med studass, slippe unna med å bare teste deler av koden. -->
2. **Enhetstestene skal skrives i JUnit 5.** 2. **Enhetstestene skal skrives i JUnit 5.**
Alle testene er skrevet i JUnit 5, med hjelp fra et par andre biblioteker og plugins som bygger på toppen av JUnit. Alle testene er skrevet i JUnit 5, med hjelp fra et par andre biblioteker og plugins som bygger på toppen av JUnit.
@ -171,4 +178,12 @@ Disse inluderer:
[controllers-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/main/java/app/controllers [controllers-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/main/java/app/controllers
[fxml-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/main/resources/fxml/ [fxml-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/main/resources/fxml/
[tests-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/test/java/app [tests-folder]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/tree/master/src/test/java/app
[interface-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/settings/SettingsProviderI.java
[settings-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/settings/SettingsProvider.java
[MenubarController-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/controllers/MenubarController.java
[LanguageChangedEvent-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/events/LanguageChangedEvent.java
[EditorChangedEvent-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/events/EditorChangedEvent.java
[ThemeChangedEvent-file]: https://gitlab.stud.idi.ntnu.no/oysteikt/h20-tdt4100-project/-/blob/master/src/main/java/app/events/ThemeChangedEvent.java