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

Design Class Diagram

<Object-oriented sub-systems should be described using a class diagram. If classes or interfaces are used across sub-systems, make sure you mention this in the description of the class diagrams. If your system entails layers, make sure you indicate this in the class diagram, e.g. by means of packages. For each class diagram, make sure you also mention the deployment artifact (from the deployment diagram) it is part of.>

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.

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

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.

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.

USECASE 3 - Beheren van competitiegroepen

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.

USECASE 4 - Beheren van spelers in competitiegroep

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.

USECASE 6 - Ronde resultaat invoeren

tekst

USECASE 7 - Resultaat externe ronde invoeren

tekst

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.