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 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.