Processing Results of JavaBall Matches

Aims and Objectives

This project assesses your ability to design and implement a solution to a well-specified
problem by a given deadline. The program should be thoroughly tested and well
documented, and use only those techniques introduced in the FP module.
Development Advice
Read your lecture notes. Try to consolidate your nowledge before starting..
Read this entire document carefully and ensure that you understand what is
required before starting wor on the design and development of your program.
!eep earlier versions of your program so that you can submit your most recent
successful version, or go bac to an earlier version if necessary..
Support
"n the first wee of #emester Two practical support will be offered by one tutor in the
lab anne$, each day % &' pm. The tutor will not come to your machine - bring a
program listing and e$plain the problem The support is intended to (mop up) your
remaining problems rather than to support you in the entire development process.
Program Contet
The favourite sport in the country of *ilyban is the team game +ava,all. -ou are to
produce a program that manages and processes results of +ava,all tournaments.
!unctionalit"
1. The functionality of the program should be accessed by a ./". -ou are free to
design this as you choose, using one or more windows.
2. 0 Te$t File giving the names of the Teams, one per line, should be read in
automatically at the start of the program. The te$t file, TeamsIn.txt,is ordered
on the team name, and will contain between 1 and 2 teams. Team names are never
more than 34 characters long, and will not contain spaces. There will not be more
than 2 teams. -ou may assume that the file contains valid data. "f the te$t file is not
found, it is acceptable to display a message before the program terminates.
3. 5ach team will play every other team. 0s part of the initialisation, the program
should produce a list of all the matches and display this in a te$t area, indicating
that as yet there are no results.
For the match display, the matches and the teams should be in alphabetical order.
i.e. within a match 6 Abbey v Par 78T Par v Abbey
within the match list 6 Abbey v Ford then Abbey v Par then Ford v Par
0 line from the display might loo lie 6
Abbey v Park *** no results yet ***
4. "t 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 eep details to show that
MSc/PgDip IT Further Programming Project Page 1 of 6 26/09/14 12:40
!#R$%&R PRO'RAMM()'
Programming Project *++,-. /,0
the team was entered and then withdrawn 6 all trace of the team can be removed at
this stage.
"f fewer than three teams remain, a message should be produced to say that the
tournament has been cancelled, and then the program terminates.
Teams will not withdraw once the result te$t file has been processed.
5. The te$t file containing most of the results will be called ResultsIn.txt.
8n request via a button clic, the te$t file should be read, and the results
processed. The display of matches should be updated to show these results. -ou
may assume that the file contains valid data, with no duplicates of match details. "f
the te$t file is not found, it is acceptable to display a message before the program
terminates. -ou cannot assume anything about the order of the teams within the
matches, or the order of the matches themselves in the te$t file.
9etails of each match are supplied on a single line consisting of
0 team name
The number of goals scored by the first team
0nother team name
The number of goals scored by the second team
For e$ample6
Park 2 Ford 2
Abbey 0 Ford 1
The display of matches should be updated to show these results. 5.g. 6
Abbey 0 Ford 1
Abbey v Park *** no results yet ***
Ford 2 Park 2
6. The remaining results are then entered via a ./". 5nsure that the user is not able
to enter details for matches that have already had their results allocated. 8ne
possibility is to provide the user with a foolproof means of entering the team names
for those matches that do not yet have results, for instance a combo bo$ showing
only those matches. There is no requirement to amend results. The scores must
be an integer between one and si$. 0gain, either do not allow the user to enter an
incorrect score, or produce an appropriate error message. 9ue to the nature of the
game, it is not possible for a team to score
more than : goals per game.
0 possible grid is shown here.

8nce all the match results have been entered, the following functionality must become
available.
7. 8n request, the program should display a bar chart showing % bars for
each team. The first bar shows the overall number of goals that this
team scored, and the second, adjacent bar shows the overall number of
goals scored against the team. The teams should be identified in the
chart by their name, and displayed in name order. Provide a title and a
ey. 0 fragment is shown here.
MSc/PgDip IT Further Programming Project Page 2 of 6 26/09/14 12:40
. ;hen all the results have been supplied, the program will process the results and
produce a raned table as shown in the screenshot. <ost of the headings are self
e$planatory.
<atch points are calculated by allocating ' points for each match won, 3
point for each match drawn.
The goal difference is the number of goals 0gainst, subtracted from the
number of goals For.
The teams are listed in order of total <atch points then .oal difference. "f
two teams have the same number of <atch points, the team with the higher
goal difference should be listed first.
The top teams are allocated medals, .old, #ilver and ,ron=e. -ou should
assume for the purposes of this project that there will be no teams with
equal match points and equal goal differences.
!. There should be an (e$it) button. ;hen this button is cliced, the list of results is
written to an output te$t file, in e$actly the same format as the te$t area display.
The te$t file should be called "Results#ut.txt$. Then the program e$its.
10. >reate a jar file and a batch file so that by placing a shortcut icon on the des
top the program can be run by double clicing the icon.
The jar file should be called FPProj.jar.
The batch file should be called FPProj.bat.
!T"S ! T"#T FI$"S
%fter &u'mi&&ion (our program )i** 'e te&te+, &o it i& particu*ar*( important that (our
fi*ehan+*ing )ithin the program +oe& !T refer to the a'&o*ute *ocation of (our te-t
fi*e&. /hen te&ting (our program )ithin et0ean& &tore (our +ata fi*e& in the current
/or1ing Director( 2norma**( 0Data in the $a' en3ironment4. P*ea&e +o !T u&e
5Fi*e6hoo&er : it i& too time7con&uming for u& )hen )e te&t (our program&8
(mplementation
/se the techniques introduced in the FP module 9o not use the 7etbeans drag and
drop interface
What is important
9esign and documentation. 0ccuracy. ?alidation that we have requested. 0ccurate
status report. Time management is part of this assessment.
What is NOT important
Fine details of the ./" layout.
?alidation that we have not requested. ".g. Te$t files are considered to be correctly
formatted so don)t waste time checing these
MSc/PgDip IT Further Programming Project Page 9 of 6 26/09/14 12:40
1ariations in the specification
9o 78T e$tend the specification@ you will not get a better mar by doing so

Recommended reduced specification
#tudents who are having difficulty with programming should submit a program with
some aspects of functionality omitted, such as the barchart, or the 9elete function.
Remember that you are unliely to get any mars for an incomplete or non-functioning
section of code.
Mar2ing Scheme
0 similar approach will be taen to that used in assessed e$ercises.
Functionality 6 :4A 9esign 6 %4A 9ocumentation 6 %4A
MSc/PgDip IT Further Programming Project Page 4 of 6 26/09/14 12:40
Project Submission
DEADLINE Wednesda Fe! "st # pm $ part%time students Thu Fe! &nd'
;0R7"7.#6 ;hen the new semester starts, you will need to give a considerable
amount of attention to choosing your elective modules. Plan your time accordingly.
0 program submitted late without an e$tension may have its mar reduced.
-our program will be tested after submission as part of the grading process. The
project must be submitted electronically by 0<# and in hard copy as specified below.
;e would lie you to include your own input and output te$t files and some screen
dumps of the ./" using these files. These are important in case your program cannot
cope with our files, either on submission or during later testing.
AMS 3not available until semester t4o5
-our main class, input and output te$t files </#T be named as requested in the
specification, and located in the Prog folder within your ;orspace named FPProj.
This folder should be in the same folder as your #emester 3 programming e$ercises.
(u!mission
-our program will be run once, with hidden te$t files. BThis means that temporarily any
of your own te$t files in your FPProj folder will be renamed so that our te$t files can
be placed in your folder and usedC.
-ou should then tae the following action6
Process the main results file
0dd in the following details to complete the results.
o 0bbey 4 Par 3
o Dillend % 0bbey %
>lose the program, thereby producing the output te$t file.
The files are then gathered.
your .java files Bthe main one </#T be called FPProj.javaC
your jar file and batch file Bcalled FPProj.jar and FPProj.batC
the output te$t file produced during the submit run
;e will 78T gather a status report electronically, as this is to be included in
the documentation.
%ard Cop"
Dard copy Bdescribed belowC must be handed in to the Teaching 8ffice, 3E *ilyban
.dns. any day in office hours BF.3G &34.3G, % &', 1.3G-1.1GC, or <on to ;ed in the
last wee any time before the deadline e$cept 34.1G - 33.3G, 3%.'4 - %.'4, '.1G - 1.3G
B8! on ;ed up to 1.44C
Part time students should hand their hard copy in by Thu %
nd
Feb
0ll documentation is to be submitted in a transparent envelope with a stud closure.
The folder must include hard copy of the following on loose sheets in the order below
3. 7ame and Title Page
%. Table of >ontents
'. #tatus Report Bsee separate sectionC
1. -our own input files, screen dumps and output files
MSc/PgDip IT Further Programming Project Page : of 6 26/09/14 12:40
a. The input files used to create bC and cC below
b. 0 few screen dumps of your ./"BsC, showing your own data
c. The te$t output file from your own data
G. Program listings
5nsure that these are legible6 use the default settings for comments, eywords
etc from 7et,eans in the lab. 0lternatively distinguish these features in colour.
0rrange your code so that the lines do not have to be wrapped.
9ocument the author of any code not your own.
Please chec that everything is included. -our program listings should
correspond to those submitted.
:. 9ocumentation
/<* diagrams as described below. -ou are welcome to use any appropriate
software to produce /<* diagrams, but it is probably quicer to just adapt the
ones supplied in the lecture B31C, or create your own using a drawing pacage
such as PowerPoint.
o /<* >lass 9iagram showing instance variables and methods Buse H for
methods called by other classes, - for (helper) methodsC. >ut and paste
method headers to save time. .roup methods by topic and annotate
Be.g. //&earchingC
o /<* 8verview >lass 9iagram, showing how your classes relate to
each other
0 +avadoc listing for 875 of your classes Bnot one involving a ./" thoughC.
This can be % per side.
Status Report
No more than an A) pa*e. >redit will be given for a well structured report.
"t should state any section of the specification not completed. "f your program
does meet our specification, all that is needed is 875 sentence stating this.
"t should also include a concise report on6
o any special cases and assumptions which affect the running of the
program
o any nown omissions or deficiencies, with respect to our specification.
-ou will be given some credit for analysing failures in a logical way. 9o
not discuss possible improvements to the original specification.
-ou are not ased to include details of your testing. Dowever you are advised
that failure to report deficiencies in code will be penalised. 0fter submission,
each program will be tested thoroughly as part of the maring process. 0ny
problems found in testing which are not documented will automatically be
considered as more serious than those documented and it will be assumed that
your testing has been incomplete.
6hat %appens 7ater
;e print the runlog, comlog and output files from the submission runs
;e run the similarity comparison I plagiarism detection program
;e run your program, testing for correctness.
;e assess the hard copy of your program and documentation
MSc/PgDip IT Further Programming Project Page 6 of 6 26/09/14 12:40