Specification
Scenario
MSc CS+ Java Test 2018-19
Processing Results of JavaBall Matches
The favourite sport in the country of Hibernia is the team game JavaBall. You are to produce a program that manages and processes results of JavaBall matches in a given tournament.
Functionality
- The functionality of the program should be accessed by a GUI. You are free to design this as you choose, using one or more windows.
- A text file giving the names of the teams taking part in the JavaBall tournament should be read in automatically at the start of the program. The text file, TeamsIn.txt, contains one team name per line, and will contain between 4 and 8 teams. Team names are never more than 10 characters long, and will not contain spaces. Team names are listed in the file in an arbitrary order, however you may assume that the file contains valid data. If the text file is not found, the program should display an appropriate message and then terminate. For an example of a possible TeamsIn.txt file, see the appendix.
- Each team will play every other team exactly once. As part of the initialisation, the program should produce a list of all the matches and display this in a text area, indicating that as yet there are no results. For the match display, the matches and the teams should be in alphabetical order of the first team name, and within the match list, matches with equal first team should be broken alphabetically on the second team name. For example:
o within a match : Abbey v Park, NOT Park v Abbey;
o within the match list: Abbey v Ford then Abbey v Park then Ford v Park.
A line from the display might look like:
Abbey v Park *** no results yet ***
You should calculate what the maximum possible number of matches could be, and ensure that the GUI is capable of displaying that many matches if necessary.
4. It is possible for a team to withdraw from the tournament after the list of matches has been created. The user should be able to specify the team to be withdrawn, and the program must then remove all the matches which include this team name, and then update the display of matches. There will be no need to keep details to show that the team was entered and then withdrawn: all trace of the team can be removed at this stage.
MSc CS+ Java Test 1
If fewer than three teams remain, a message should be produced to say that the tournament has been cancelled, and the program should then terminate.
5. A text file containing some (possibly all, but usually most) of the results will be called ResultsIn.txt. On request via a button click, the text file should be read, and the results should be processed as described below. Note that ResultsIn.txt could contain results for a team t that has withdrawn from the tournament (for example, if t withdrew halfway through the season) – all results involving t that are read in from the results file should be ignored. Teams will not withdraw once the results file has been processed. The display of matches should be updated to show these results. You may assume that the file contains valid data, with no duplications of match details. However you cannot assume anything about the order of the teams within the matches, or the order of the matches themselves in the text file. If the text file is not found, the program should display an appropriate message and then terminate.
Details of each match are supplied on a single line consisting of:
o a team name;
o the number of goals scored by the first team;
o another team name;
o the number of goals scored by the second team.
For example:
Park 2 Ford 2
Abbey 0 Ford 1
The display of matches should be updated to show these results. E.g.,
Abbey0 Ford 1
Abbey v Ford 2
Park *** no result yet Park 2
For a complete example of a possible ResultsIn.txt file, see the appendix. This file should be read in exactly once during a single execution of your program.
- The remaining results are then entered manually via a GUI. The functionality to add results manually should only be enabled after ResultsIn.txt has been read in. Ensure that the user is not able to enter details for matches that have already had their results allocated (there is no requirement to amend existing results). The goals scored must be an integer between 0 and 9. Again, either do not allow the user to enter an incorrect score, or produce an appropriate error message. Due to the nature of the game, it is not possible for a team to score more than 9 goals per match.
- When all the match results have been supplied, the program must (on request via a button) make available the functionality to process the results and produce a ranked table as shown in the screenshot below. The entries in the various columns are calculated as follows (some column headings are self-explanatory):
MSc CS+
Java Test 2
o o o
match points are calculated by allocating 3 points for each match won, and 1 point for each match drawn;
the goal difference for a team t is the total number of goals scored against t, subtracted from the total number of goals scored by t;
the teams are listed in order of total match points then goal difference. That is, if two or more teams have the same number of match points, the teams should then be
ranked by goal difference (the team with the highest goal difference should be listed
first);
o the ranking of each team is indicated, and this might need to reflect the possibility
that two or more teams have equal points and equal goal difference. In the example
below, both Bournevale and Park have rank 2, whilst the next team, Park, has rank 4. o the top teams are allocated medals, namely Gold, Silver and Bronze, as follows: the top-ranked team (or group of teams) are awarded Gold, the second-top-ranked team/s are awarded Silver, whilst the third-top-ranked team/s are awarded Bronze, as
in the example below.
Matches Goals Match Goal Team Rank Won Drawn Lost For Against Points Diff
Medal Gold Silver Silver Bronze
Hillend 1 3 Bournevale 2 1 Park22 Abbey 4 2 Ford 5 0 Cragfoot 6 0
2 0 4 0 1 2 1 2 4 1 2 3
19 12 11 7
8. There should be an ‘exit’ button. When this button is clicked, the text area display should be written to an output text file called ResultsOut.txt. That is, if the results have not yet been processed, ResultsOut.txt should contain a list of the matches together with the results that have been entered so far. Otherwise ResultsOut.txt should contain the ranked table as illustrate above. After producing the output file, the program should terminate. To ensure that the user cannot exit the program without creating the output file, the normal close button of the main GUI frame should be disabled.
NOTES ON TEXT FILES
After submission your program will be tested, so it is particularly important that your file- handling within the program does NOT refer to the absolute location of your text files. When testing your program within Eclipse, store your data files in the current working directory (i.e., the same one that contains your Java program). Please do NOT use JFileChooser: it is too time-consuming when testing your program!
Getting started
Launch Eclipse. You should ensure that your workspace is set to H:\workspace\Prog. Use “Switch Workspace->Other” under the File menu to check your workspace location. If you need to change it, note that Eclipse will restart.
Create a new Java project called ProgProj in your workspace. You must ensure that in the project creation wizard, you choose the option “use project folder as root for sources and class files”. If you find that folder ProgProj has sub-folders src and bin, you have chosen the wrong option and should delete the project and create it again.
Development Advice
o Read this entire document carefully and ensure that you understand what is required before starting work on the design and development of your program.
MSc CS+ Java Test 3
9 6 12 9 6 8 9 14 6 12
7 3 73 7 -2 4 -5 2 -6
o Keep earlier versions of your program so that you can submit your most recent successful version, or go back to an earlier version if necessary. You should design your program incrementally, testing each class and method as it is developed. When you have got a particular stage working, make sure that you save a copy of your working file under a different name so that you can revert to an older working version if necessary. Even if some parts of the program are not working, try to ensure above all that the program compiles!
o It is not advisable to create a program with additional functionality to that required by the specification. (For example, you can assume that input text files are correctly formatted, so you need not waste time validating these.) You will not get extra credit by extending the specification (gold plating).
o Students who are having difficulty with programming should submit a program with some aspects of the functionality omitted, such as the withdraw function.
o Fine details of the GUI (colour scheme, font size etc.) are not important, however there is credit for GUI design which primarily relate to “usability” issues, and how they impact on functionality. For example, a text field with no label beside it may not, strictly speaking, in itself cause the program to output an incorrect result, but it makes it very difficult for a user to know exactly what should be entered in that text field!
Marking
You should demonstrate your working program in one of the lab sessions and will receive a grade of either A:excellent, B:very good, C:good, D:poor, E: very poor.
These marks do not contribute towards your final grade but will be used to provide feedback both to you on the sort of programming experience we expect, and to us on your programming ability before the main courses start.
You do not have to finish the program to get a good grade. You should aim to finish with a working program with some functionality missing, rather than a complete program with bugs.
If you are graded with D, and especially E, then you should meet with your program director to discuss transferring to a different program which will bring your programming up to speed. If you find at an early stage that this exercise is beyond you then you can meet with the program director straight away, rather than waiting until the end of the week.
It is not possible to catch up with programming while simultaneously taking your normal courses. Our programs are quite intensive and do not contain slack time for additional preparatory work.
MSc CS+ Java Test 4
Appendix – format of the input files
The following is an example of a possible TeamsIn.txt file:
Ford Bournevale Park Cragfoot Abbey Hillend
The following is an example of a possible ResultsIn.txt file:
Park 0 Hillend 3 Ford 0 Abbey 0 Cragfoot 0 Bournevale 0 Bournevale 3 Ford 3 Hillend 6 Cragfoot 3 Abbey 0 Bournevale 3 Ford 0 Cragfoot 0 Bournevale 2 Hillend 2 Cragfoot 2 Park 4 Ford 5 Hillend 5 Bournevale 1 Park 1 Park 6 Ford 1 Abbey 2 Cragfoot 1
MSc CS+
Java Test 5