...
Voor de packages zijn een aantal keuzes gemaakt. Als eerste is er per klasse type een package gemaakt. Voor de repository klassen is dus een repositories package gemaakt, en voor de mapper klassen is een mappers package gemaakt. In de app package zitten alle controlerscontrollers, zoals te heeft deze een connectie met services en repositories. Normaal gesproken zouden de controllers via de service een connectie hebben met de repositories. Bij ons was dit in het begin ook het geval, maar in sommige service klassen zat eigenlijk totaal geen functionaliteit en roepte het riepen deze alleen de repository aan, dit vonden wij niet echt nutting nuttig en daarom zijn er enkele repositories zonder services waardoor de app package een directe connectie met de service package moet hebben. Ook is er gekozen om een algemene algemeen utils package te maken, hierin staan vooral wat losse klassen die niet echt bij een andere package passen. In de repositories package zit ook een utils package, dit is gedaan voor de EntityManagerFactory. DeEntityManagerFactory De EntityManagerFactory hoort niet echt direct bij de repositories en daarom zit deze in een aparte package.
...
In de App package zitten vooral de main klassen van de applicatie zoals de MainWrapper en de Controller klassen. Om de applicatie te starten moet de main methode van de MainWrapper klasse aangroepen worden. In de Controller klassen staat alle code waarmee de front-end geregeld wordt. Voor elk scherm in de applicatie is een aparte controller gemaakt die communiceert met het front-end bestandjebestand. Op deze manier is de code van elke scherm gescheiden van elkaar.
...
De Entity klassen zijn eigenlijk een soort representatie van de database. De attributen van de entity klassen moeten overeen komen met de kolommen uit de database. De repositories gebruiken deze entities om data uit de database op te halen en daarom zijn deze entities dus gemaakt. Door entities samen met JPA te gebruiken kan er makkelijker geswitcht gewisseld worden tussen database systemen omdat de JPA taal zelf regelt met welk database systeem gecommuniceert wordt.
...
In dit class diagram staan de exceptions die binnen het systeem gebruikt worden. De DatabaseException wordt gebruikt voor foutmeldingen die omhoogkomen bij het gebruik van de database. Naast de DatabaseException is er ook nog een ResourceException en een UserInputException. De ResourceException is net zoals de DatabaseException een RuntimeException en handelt foutmeldingen af die ontstaan door ontbrekende data. Stel dat er bijvoorbeeld een FXML bestand mist binnen de applicatie moet er wel een manier zijn om deze error op te vangen. Hierbij wordt dan dus de ResourceException gebruikt. Als laatste is er ook nog een UserInputException. Deze exception wordt gebruikt voor foutmeldingen die te maken hebben met de input die de gebruiker van de applicatie (onbedoeld) creëert. Stel dat de gebruiker een fout maakt met het invoeren van een rating, zo kan het zijn dat hij bijvoorbeeld bijvoorbeeld dat deze per ongeluk wat letters invoert waar die niet de bedoeling is, dan wordt er met de UserInputException gewerkt om deze error af te handelen.
...
Sequence Diagrams
SD UC1.2 createPlayer
SD UC2.1 createCompetition
CalculateNewRating
Voor het berekenen van de score heb je drie waarden nodig: rating1, rating2 en de score van rating1. De functie berekent altijd de score voor rating1. Als eerste wordt een expected score berekend, dit is een getal tussen 0 en 1. Met de rating, K-factor, score en expected score expectedScore wordt de nieuwe rating berekend.
Dit systeem is gemaakt op basis van informatie uit de wikipedia Wikipedia pagina van een "Elo rating system": (Hoofdstuk Hoofdstuk Mathematical_details). Het gebruikte systeem wordt bij de FIDE (International Chess Federation) ook gebruikt.
...
Het indelingssysteem voor Meerkamp maakt gebruik van een indeling op basis van de tabellenstructuur zoals beschreven in het door ons verrichtte onderzoek. Om deze indelingen te generen worden de spelers in zowel een lijst voor witte als zwarte spelers ingedeeld. Daarna worden deze lijsten door middel van SecureRandom gehusseld en wordt er daarna per ronde voor de matches een indeling gemaakt op basis van deze twee lijsten. Elke gemaakte matchup wordt tijdelijk opgeslagen om te voorkomen dat dezelfde indeling twee keer voorkomt. Op deze manier is elke meerkamp indeling anders en weten we zeker dat iedere speler altijd tegen elkaar speelt.
Indien een groep een oneven aantal spelers heeft wordt degene die overblijft ingedeeld tegenover een niet-ingevulde zwarte speler en wordt de match oneven verklaard. Nog steeds word ernaar gekeken dat elke speler tegen elkaar speelt.
Periodecompetitie
Het indelingssysteem voor de periodecompetitie gebruikt verschillende schema's om de zijn indeling te maken. Deze schema's worden gekozen voordat de indeling gemaakt wordt gemaakt. De gebruiker moet kunnen kiezen in welk schema de competitie gegenereerd wordt gegenereerd, vandaar dat dit van tevoren wordt het van te voren is gedaan.
De functie begint met het sorteren van de spelers op de volgorde van hoogste rating naar het laagste om te zorgen dat de gekregen schema's goed zouden werken. Hierna wordt er gecontroleerd hoeveel spelers er in de gekozen groep zit, zodat er rekening kan worden gehouden met eventuele oneven spelersaantallen. Een null speler match met een ontbrekende speler (null) wordt bij ons als oneven getoond in de matches tabellen binnen een groep.
Hierna wordt de juiste goede variatie gekozen door d.m.v. het aantal spelers te controleren. Dit is gedaan met een switch - case , omdat dit het gemakkelijk maakt om in de toekomst zo makkelijk is om mogelijk nieuwe opties toe te voegen in de toekomst. Om de wedstrijden matches te genereren , wordt er door de variatietabel gelopen, zodat dit variaties tabel geloopt zodat het altijd voor het juiste aantal rondes gebeurt. Mocht er dus een nieuwe variatie komen binnen de variatietabel variatie tabel met bijvoorbeeld 6 rondes in plaats van 5, i.p.v. 5 dan zal het systeem zich hierop zichzelf er op aanpassen.
Binnen deze loop van de rondes genereert wordt er door generateLayout de matches gegenereerd. Deze matches worden toegevoegd aan een lijst list van matches. De spelerslijst wordt , samen met de rondevariatieronde variatie, een ronde-ID rondeID en een groep-ID, groepID gebruikt om de matches te maken. Van tevoren ter voren worden de spelers omgezet naar spelers players 1 en 2 in dezelfde volgorde , van hoge rating naar lage rating.
Om te zorgen dat de mogelijk toegevoegde null speler ( oneven speler ) goed neergezet wordt wordt het dit hierna gecheckt. Mocht er een null speler zijn wordt deze altijd neergezet als de zwartspeler. Het resultaat kan ook al worden ingevoerd in dit geval.
...
Daarna worden de matches uit de geretourneerde layout gehaald om deze op te zetten in de database.
Toernooi
tekst
Patterns
Strategy pattern
TODO
Layered architecture
TODO
MVC pattern
TODO
Overig
JaVaFo
Voor het genereren van een competitionlayout van een toernooi is een extern programma gebruikt, omdat het genereren van een zwitserse indeling wellicht te foutgevoelig zou zijn als het geprogrammeerd werd door iemand die niet volledig thuis is in het domein. JaVaFo, gemaakt door Roberto Ricca, is een in Java geprogrammeerde matchmaking software. Het heeft als input een document nodig dat specifiek is aan de schaakorganisatie Fide (.trf). Om dit te genereren zijn er een aantal classes aangemaakt om dit te regelen. "DocumentMaker" kan met wat speciale DTOs waar de data in is opgeslagen een string genereren waarmee JaVaFo een indeling kan maken. "JaVaFoDocuPlayer" en "JaVaFoDocuResult" zijn DTO's om de data van spelers en ronderesultaten op te slaan. JaVaFo maakt van de input van DocumentMaker een output string die vervolgens vertaald kan worden naar match DTO's.
...