Go to file
Leonardo Brandenberger 73ba3b3b9e Created Readme 2022-05-13 23:48:13 +02:00
app extend dictionary 2022-05-13 20:53:33 +02:00
gradle/wrapper created gradle application 2022-04-22 10:10:20 +02:00
.gitignore created simple classes 2022-04-22 11:42:39 +02:00
ClassDiagram.png uploaded ClassDiagram.png 2022-05-13 22:08:20 +02:00
README.md Created Readme 2022-05-13 23:48:13 +02:00
gradlew created gradle application 2022-04-22 10:10:20 +02:00
gradlew.bat implemented functionality of PlacesFormular 2022-05-01 22:43:41 +02:00
settings.gradle created gradle application 2022-04-22 10:10:20 +02:00

README.md

team02-AngryNerds-projekt2-turnierverwaltung

Tournament administration

Documentation

Our Tournament Administration Tool is available in german and english, to change the language click on start in the top left corner and then select your desired language under 'Sprache' or 'Language' (documentation is only provided in english).

Once you start the Programm you will be presented with the possibility to either create a new tournament or load one if one has already been saved.

To create a new tournament simply type in the name of it and press create

To load a tournament select the tournament on the list and click open

You can also delete a tournament by selecting it and then clicking delete

Once a tournament has been created you will be sent to the tournament screen. Your next step should be adding a place or players you can do so vie Edit Participants or Edit Locations.

Once you have enough Players(min 4 and only number that are 2^n e.g. 4, 8, 16...), you can click the Create game schedule button and the schedule will be created

you can then input the location where a game takes place and as well the points a team scored the winning team will then automatically advance in the tree.

The Programm automatically saves, so no worries you won't lose your progress.

Startup and Testing

To Start the Programm use the command

./gradlew run

To run the tests use the command

./gradlew test

Branching Model

We used a simple branching model, for each new functionality or working step a new branch would be created, once a segment was finished the branch would then be reviewed by peers and be pushed into the main branch via a pull request, no direct work is usually done in the main branch.

Class Diagramm

Our class Diagramm can be found here

Architecture

Our Model View Pattern has been set, so that the class Tournament acts as the Model. Each View has its own unique controller assigned For Comprehensive Reasons all Controller Classes inherit from the abstract super class FX Controller.

The Class Tournament decorator has the purpose of communication of the controller classes with the Model of the tournament, the same Decorator also communicates with the FileIO and inherits the task of saving or importing save files into the program.

The Class Tournament Decorator always stores the Tournament that is opened in a data field. The Factory and its associated Factory Decorators are responsible to load all the views if application is started. And to switch between the views while using the application.

The Factory decorator is placed between the controllers and the factory to enable the communication.

The Model tournament saves a List of all participants, all places and all games. Participants are implemented as an interface, since we want to be able to save a team or a single player as participant (in the prototype it is not possible to create a team).

To refresh the view of the tournament tree, each game has its own game decorator with a list of listeners.

To realize the tree there are listeners placed in the game decorators of the previous round to gather the winner and calculate the new participants of a game. Listeners are only placed

Loggers are implemented in all relevant classes Each class creates its own logger a root logger is created in the LogConfiguration class and two Handlers are specified for use, one File Handler and one Console Handler. The setting of those handlers can be set in the file log.properties.

We choose this architecture since it gives us the advantage to add more views without having any more code duplication. We also think it is an advantage that the saving automatically takes place and the user does not have to take into consideration to save from time to time. It also closely resembles what we learned already in lectures we had previously, so we were able to implement it accordingly.

Notable Pullrequests

Number 1 Number 2