Introduction

Overall Description

Zie 1.1. Algemene beschrijving van het SRS.

Purpose of this document

In dit document worden ontwerpbeslissingen beargumenteerd en wordt laten zien hoe het systeem in elkaar zit. Onze applicatie bestaat alleen uit java code en dit is dus ook het enige systeem dat uitgewerkt zal worden. 

Architectural Overview

<Provide a high level overview of the architectural design, for instance by means of an architectural sketch. Make sure you show at least all sub-systems, and links to external systems. The sketch can be informal. The use of UML is not required.>

Detailed Design Description

Deployment Diagram

Database Design

Zie hier het gemaakte PDM. Samen met het PDM bestand in de bestandenlijst dat o.a. te openen is via Powerdesigner zou het duidelijkheid moeten brengen over hoe het systeem in elkaar staat.

Design Class Diagrams

App package

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 wordt de nieuwe rating berekend.

Dit systeem is gemaakt op basis van informatie uit de wikipedia pagina van een "Elo rating system": (Hoofdstuk Mathematical_details). Het gebruikte systeem wordt bij de FIDE (International Chess Federation) ook gebruikt. 

Activity and State Diagrams

<This section is optional. If useful, provide activity and/or state diagrams to describe complex work flows and system state transitions>

Design decisions for the sub-systems

Usecases

USECASE 1 - Beheren van spelers

Op het scherm voor het beheren van de spelers is gekozen voor een tabel waarin alle informatie over spelers staat, met daarboven een aantal invulvelden en knoppen waarmee de data bewerkt kan worden. Dit is volgens de projectgroep de meest overzichtelijke manier om een grote lijst met spelers snel en eenvoudig te beheren. Indien nodig kan de tabel namelijk per kolom gesorteerd worden, waardoor het vinden van specifieke spelers gestroomlijnd kan verlopen. Het verwijderen van spelers en het vastleggen van de startrating zijn belangrijke handelingen, en zijn daardoor voorzien van een pop-up die om bevestiging van de actie vraagt, zodat bijvoorbeeld een speler niet per ongeluk uit de database verwijderd kan worden.

Voor deze implementatie wordt gebruikgemaakt van een servicelaag die de inputs van de gebruiker controleert op een aantal afgestelde regels, bijvoorbeeld of alle velden vereiste velden zijn ingevuld bij het invoeren van een nieuw lid of gast.

USECASE 2 - Beheren van competities

Het beheren van een competitie werkt in essentie hetzelfde als het beheren van spelers, maar een competitie heeft meer opties die de gebruiker moet kunnen bewerken, en deze opties hoeven niet in de tabel zichtbaar te zijn. Er is voor gekozen om alle instellingen voor een competitie in een kolom naast de tabel met competities te zetten. Ook is ervoor gekozen om op basis van welke soort competitie wordt gekozen bepaalde waarden automatisch in te vullen met een standaardwaarde. Dit allemaal om het gebruiken van de applicatie zo gestroomlijnd en gemakkelijk mogelijk te maken.

Ondanks dat er geen gebruik van wordt gemaakt is er ook voor gekozen om het aantal punten dat kan worden verdiend met een winst, verlies, gelijkspel etc. aanpasbaar te maken. Dit maakt Klukkluk flexibel mocht deze functionaliteit later gewenst zijn.

Ook deze usecase maakt gebruik van een servicelaag om de inputs van de gebruiker te controleren.

USECASE 3 & 4 - Beheren van competitiegroepen & Beheren van spelers in competitiegroep

Op het scherm voor het beheren van competities is een nieuwe knop toegevoegd die de gebruiker naar het scherm voor groepsbeheer van de desbetreffende groep brengt. Als een nieuwe competitie wordt aangemaakt worden (indien relevant) op basis van een standaard aantal een aantal groepen automatisch gegenereerd. Op dit scherm worden CRUD operaties met betrekking tot groepen verwerkt. De gebruiker kan de naam van de groep aangeven, waarna het systeem vervolgens een nieuwe GroupDTO zonder spelers aanmaakt en via de repository toevoegt aan de database.

Er waren voor het implementeren van competitiegroepen geen ingewikkelde beslissingen of oplossingen. Het betreft voornamelijk simpele CRUD-operaties waarvoor de implementatie relatief gemakkelijk is. Wel is voor deze implementatie gekozen om geen gebruik te maken van een servicelaag, omdat alleen de naam van de competitiegroep gedefinieerd kan worden.

Op dit scherm kan de gebruiker een of meerdere spelers van of naar groepen verplaatsen. Door op CRTL + Linker muisklik te drukken kunnen meerdere spelers geselecteerd worden. Aan de hand hiervan stuurt het systeem vervolgens ofwel een enkele of een lijst van DTO's naar de repository, die vervolgens de juiste functie uitvoert om de speler in de groep te zetten of deze eruit te verwijderen. In het geval dat de gebruiker meerdere spelers tegelijkertijd wil invoeren, aanpassen of verwijderen wordt aan de uit te voeren query steeds een nieuwe regel met spelerdata toegevoegd.

In deze implementatie is de servicelaag weggelaten. Het betreft namelijk alleen het overzetten van al bestaande, en dus al gecontroleerde data, waardoor het uitvoeren van datacontrole in de servicelaag niet nodig is.

----------

Het scherm voor het beheren van competitiegroepen bevat veel informatie. Hierom is ervoor gekozen om de data weer te geven in een drietal tabellen, waarbij er onderscheid gemaakt wordt tussen de spelers die niet in een groep zitten, de groepen van de competitie, en de spelers die in de geselecteerde groep zitten. Op deze manier heeft de gebruiker overzicht over in welke groep deze bezig is, welke spelers hierin zitten en welke niet.

Als een competitie wordt aangemaakt worden aan de hand van het op het competitiescherm gekozen aantal, een aantal groepen automatisch aangemaakt, gelabeld "A, B, C" enzovoort.

Er is voor deze implementatie geen servicelaag aanwezig, er is namelijk bij het aanmaken van de groepen geen data aanwezig die de gebruiker op dit scherm aan kan passen. Het enige wat de gebruiker aan kan passen is de naam van de gegenereerde groepen.

USECASE 6 - Ronde resultaat invoeren

Bij het invoeren van ronde resultaten is gekozen om een scherm te maken waar je op basis van een groep de ronden en wedstrijden kunt zien, zodat duidelijk waar een wedstrijd bij hoort. Voor het invoeren van resultaten zijn er keyboard shortcuts gemaakt voor Wins, Verlies en Gelijk, deze knoppen kun je activeren door op F1,F2 of F3 te drukken. Dit maakt het makkelijker voor de gebruiker om resultaten in te voeren omdat er niet steeds op een knop gedrukt hoeft te worden. In de tabel is ook nog een systeem gemaakt waarmee de geselecteerde rij automatisch een naar beneden springt nadat er een resultaat ingevoert wordt, hierdoor hoef je dus niet steeds opnieuw op een tabel rij te drukken om een resultaat in te voeren.

USECASE 7 - Resultaat externe ronde invoeren

Het invoeren van resultaten bij extern gespeelde rondes werkt op basis van de rating van de externe speler. De gebruiker kan een searchable combobox (drop-down menu) gebruiken om de juiste speler uit de database te selecteren, waarna er in een invulveld de rating van de externe speler ingevuld kan worden. Daarna kan de uitslag van de match uit een drop-down menu gekozen worden.

Het aanpassen van de rating van een speler is een belangrijke actie, daarom wordt er zodra de gebruiker op "opslaan" drukt een pop-up weergegeven met de vraag of de aanpassing bevestigt moet worden. Op deze pop-up wordt ook de nieuwe rating van de speler al getoond.

Er is gekozen voor een searchable combobox omdat deze in het geval van deze usecase voldoende informatie kan tonen, en het zoeken van enkele spelers eenvoudiger maakt dan een gehele tabel door moeten spitten.

USECASE 8 - Indeling genereren voor competitie

Het genereren van indelingen gaat op basis van vooraf gedefiniëerde systemen. Dit betekent dat de gebruiker, nadat deze groepen heeft gemaakt, alleen maar aan Klukkluk hoeft aan te geven dat deze indelingen wil laten genereren. De applicatie zal hierna op basis van het competitietype en de geselecteerde manier van indelen (relevant bij Heller-tabellen, waarbij er verschillende varianten zijn) de spelers in de groepen automatisch in rondes indelen.

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.

Bij het maken van de inputstring is de spacing van alle waardes erg belangrijk, waarvoor "inflate" functies zijn gemaakt. Deze functies voegen white space (' ') tekens toe, tot de input string gelijk is aan de lengte die voor dat stuk nodig is. Bij nummers wordt inflate left gebruikt (want 0-9 moeten op de meest rechtse plaats staan, en moeten naar links uitbreiden) en bij letters wordt inflate right gebruikt (want het eerste teken moet zo links mogelijk staan en naar rechts uitbreiden).