dissertation - a fixtures solution

8/4/2019 Dissertation - A Fixtures Solution

1/137

A Fixture Timetabling Solution

Author: Michael Thomas Davis

Supervisor: John Colquhoun

Word Count: 20,251


2/137

Michael Thomas Davis A Fixtures Timetabling Solution

2

Abstract

Current Premier League fixtures are often subject to criticism by fans as games between clubs hundreds

of miles away can take at inconvenient times making travel difficult and expensive. The aim of this

project is to produce a program which, when given a set of teams and a set of user-defined rules and

criteria, will generate a fixture list. Current Premier League fixtures are often subject to criticism by fans

as games between clubs hundreds of miles away can take at inconvenient times making travel difficult

and expensive. During my time working at Everton Football Club I would often hear first-hand fans

frustration at the current fixtures list, an example of this was during the 2010/2011 season when Everton

were scheduled to play an away game with Sunderland (a club over 3 hours away) at 8pm on a Monday

night.

Acknowledgements

I would like to thank John Colquhoun for his much needed support, guidance and above all else his

patience. Id also like to thank my Mother who has always put my education first and for that I am

eternally grateful.

Declaration

I declare that this dissertation represents my own work except where otherwise stated.

!


3/137

A Fixtures Timetabling Solution Michael Thomas Davis

! 3

Table of Contents

!"#$%&'()*&+! ,*%')-.!%,)*(////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////(0!

!"#$%&'(%1)+! 2#!34').*-('-,*4(#*-('&5#%&-(1)'3(/////////////////////////////////////////////////////////////////(67!

"#$%! &'(()*+!,--(.,&/)0!################ ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ##########!%$!

"#$"! 120&'002.*!.3!,45.(2+/60!########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ######!%%!

"#$7! +/)!0.3+8,()!)*52*))(2*5!-(.&)00!########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########!"%!

"#$9! &.*&4'02.*0!############### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ######!"7!

!"#$%&'(%"'&&+! 8&%")-)5)49(////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////(:;!

7#$%! 0.3+8,()!)0+26,+2.*!########## ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ####!":!

7#$"! (20;!6,*,5)6)*+!############### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ######!"

7#$7! -(.=)&+!-4,**2*5!########## ########### ########### ########### ########### ########### ########### ############ ########## ############ ########### ########### ########### ########### ########### !">!

7#$9! ()?'2()6)*+0!)*52*))(2*5!########## ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ####!77!

7#$:! 1)025*!6.1)4!########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########!:$!

!"#! $%&'()*&)+%*,----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------,./!

!0#! 1%"2'(&"3,45*%,67)*%8"&*,9*5(:7,------------------------------------------------------------------------------------------------------------------------------------------,.;!

!! 75,$3:>%()'?,--------------------------------------------------------- ----------------------------------------------------------- ---------------------,CD!

7#$@! +)0+2*5!########## ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ########### ##########!@7!

7#$

!"#! )>)F2*,----------------------------------------------------------------------------------------------------------------------------------------------------------------------------,C.!!0#! G*&>7A,E%>)>)F2*,-----------------------------------------------------------------------------------------------------------------------------------------------------------------------,CC !

!! H'(%A,E%>)>)F2*,---------------------------------------------------------------------------------------------------------------------------------------------------------------------------,CI!

!"#$%&'(?!

9#$%! 3'*&+2.*,4!()?'2()6)*+0!&.6-42,*&)!################## ########### ########### ########### ########### ########### ########### ########### ########### ########### ######!@A!

9#$"! *.*B3'*&+2.*,4!()?'2()6)*+0!&.6-42,*&)!########## ########### ########### ########### ########### ########### ########### ########### ########### ########### ####!


4/137


4

!"#$%&'(=,A+! #$$&*-,A(///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////(?B!

!"#$%&'(=&@&*+! 2,25,)4'#$"9(///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////(6C>!

(


5/137


! 5

Table of Figures


6/137


6

!

>!

!

!

!

/! =!'&&*(=")1,*4(4#8&1&&3(4&*&'#%,)*(////////////////////////////////////////////////////////////////////////////////////(660!


7/137


! 7

CHAPTER ONE: INTRODUCTION

The main aim of this project is to produce a program which, when given a set of teams and a set of user-

defined rules and criteria, will generate a fixture list. For the purpose of the project, the program will be

loosely aimed at football league organisers, but league organisers of any type (rugby, chess, boxing etc.)

will be able to use the tool. The program will be completely scalable from allowing amateur sports

leagues to create league fixtures to, in theory, being used by sports bodies such as The FA (Football

Association) to create Premier League fixtures.

The motivation for this project is the criticism aimed at Premier League fixtures by fans that games

between clubs situated hundreds of miles away can take place at inconvenient times making travel

difficult and expensive. During my time working at Everton Football Club (Everton 2011) I would often

hear first-hand fans frustration at the current fixtures list, an example of this was during the 2010/2011

season when Everton were scheduled to play an away game with Sunderland (a club over 3 hours away)

at 8pm on a Monday night (BBC 2010). Furthermore fixtures have been known to take place on days

when other large-scale events are taking place, causing strain on police forces and transport links (BBC

2011). The programs primary function will be to create a simple fixtures list, however its secondary

function and one that is currently not available is a program to create a fair fixtures list.

The program to be created is to be christened Fixtures Generator+; the idea behind this name is that the

plus represents the added fairness that other fixtures generators lack. This issue of fairness is an

extremely subjective one, however for the purpose of this project it will generally be interchangeable with

the distance fans travel at certain times of the day on certain days.

Traditionally fixtures are split into gameweeks of n/2 fixtures, where n is the amount of teams in the set.

If the end user wishes to have both teams play home and away, which is normally the case as to avoidaccusations of bias, then Fixtures Generator+ will create fixtures for (n-1)*2 gameweeks, the user will

however have options to have teams just play each other once thus giving n-1 gameweeks.

An example of the usefulness of the fairness feature is this; a fixtures governing body for an unspecified

sport containing twenty teams may conclude from various fan surveys and empirical research that

Saturdays at 3pm is the best time for fans to travel the greatest distances, they may also conclude that

Wednesdays at 8pm is the worst time to travel long distances. However, due to television commitments

one fixture every week must be played at Wednesdays at 8pm. Fixtures Generator+ will allow the end


8/137


8

user (normally the person in charge of deciding the fixtures) to input these criteria and receive a list of

fixtures. In this example the fixture on Wednesdays would be the least distance fixture for that week.

Of course these fixtures can and indeed have been made in the past without the use of a computer but the

ease and time savings brought about by creating such a program to do the generation is undeniable.

Premier League Football fixtures are decided by a mixture of computer program and manual

manipulation, taking many weeks to decide their fixtures (Fletcher 2009). The aim of this project is to

ultimately reduce the amount of human input to the fixtures after the program produces them. This

reduction is important as it reduces the liability on the fixture maker from accusations of bias and saves

times and effort, which in a commercial environment would save money. It would be bold to say that

computerised methods are prone to fewer errors than manual methods, but with an acceptable level of

testing this would be the case. Thus, the aims of this dissertation are as follows:

Create a complete GUI led program that allows the user to generate a fixtures list based ondefined criteria.

Take into account the distances that fans travel at various times and allow the user to rate thetimes of match by fairness.

Employee a solid Software Engineering approach to development throughout and learn from thepractical use of these techniques.

Reach a stage where a client would be satisfied with the functionality of the program.This dissertation follows the production of the program from the planning and research stages through to

the finished tool, its testing and the evaluation of the final program. It will include a Requirements

Specification as well as a Design and Test Plan, but will also encompass the following:

Brief evaluation of current football fixtures procedures, potential rules that should be includedand how they are generated.

Detailed analysis of similar algorithmic solutions such as timetabling algorithms. Analysis of Software Engineering techniques and programming languages to be used. Exploration of the concept of randomness and how random numbers produced by a computer

can be.

Designing and Testing of an appropriate algorithm at a basic level that will decide a number offixtures for any number of teams.

Evolution of algorithm to incorporate more advanced features such as rules, fairness andexternal events.


9/137


! 9

Designing of a possible Graphical User Interface and the possibility of its implementation in thefinal program.

The ensuring of all rules and regulations being followed by the algorithm when decided thefixtures list. This will be achieved by rigorous testing.

Comparing the fairness of the fixtures list to that of the Premier Leagues fixtures. Conclusions about the effectiveness of the program, its usability and potential improvements that

could be made with less time constraints.

The final program produced should be well designed, reliable and produce fixtures that conform to the

criteria set on them by the end user. The end user should have total control and flexibility of the criteria

through a GUI that is high in usability and easy to read the fixtures produced.


10/137


10

CHAPTER TWO: BACKGROUND READINGANDRELATEDWORK

2.01 Current ApproachesOne of the most well known solutions to the problem of generating fixture lists is that of the Premier

League and Football League. At present the process is handled by third party company Atos Origin

(uk.atos.net) who created the software that has been instrumental in scheduling the football fixtures for

the 92 Premier Leagues for over 20 years (Atos 2011). As would be expected the software is closed-

source and as such no analysis can be conducted. Assumptions however can be made about the criteria

based Premier League stipulations (PLA 2008), which are:

Wherever possible clubs should have no more than two successive home (or away) fixtures,excluding cup draws.

All clubs should have an alternating sequence of home and away Saturday fixtures at both thebeginning and end of the season.

Any club away on Boxing Day should be at home on New Year's Day and vice versa. Localderbies are avoided on these dates (due to the need for increased police presence) but equally

distance of journeys should be minimised. If possible, clubs should have an equal number of

home and away fixtures on Bank Holidays, if applicable.

Clubs playing in the Europa League on a Thursday will have the option of moving a Saturdayfixture to a Sunday so, where possible, these should be home matches.

As seen the current criteria does take into account distance on days such as Boxing Day and New Years

day, however from an interview with Glenn Thompson of Atos Origin (Fletcher 2009) he admits that

Boxing Day fixtures are hand picked to avoid travel times, this step away from computerisation of the

process could leave the fixtures company open to accusations of bias. As BBC sports correspondent Paul

Fletcher notes: As Thompson readily admits, the computer has no concept of the distance between

grounds. (Fletcher 2009). This lack of information available to the algorithm means that if this idea of

fairness is to be implemented then human interaction is needed. Another interesting aspect that Fletcher

(2009) notes is that clubs can submit requests that certain games are played at certain times. Around 90

such requests were received for the 2009-2010 season, with around 80% being granted. Presumably the

other 20% could not be accommodated or were considered unreasonable requests, possibly giving anunfair advantage to the requesting team.


11/137


! 11

Stepping away from professional football, there are other examples of tools that allow the generation of

fixtures, which are readily available on the Internet; these are aimed at amateur leagues of any discipline

that follows the structure of each team playing all the other teams in the league at least once. Bluebones

Fixture Generator (bluebones.net 2011) allows the inputting of team names into a textbox separated by a

new line and outputs appropriate fixtures in rounds. The solution works well if a simple output is

needed, however it does have some issues:

1) The tool uses Berger Pairing Tables (discussed later), this algorithm will always give thesame output, no matter now many times it is run (with the same inputs in the same order). For

example if 14 teams are inputted, Team 1 will always play Team 14 in the first week, Team 2

will play Team 13 etc.

2) The second half of the season is a mirror of the first half.3) The tool has no concept of rules and regulations that each body would put in place nor does it

have any concept of distance.

One thing the source code of the bluebones tool demonstrates well is the use of a ghost for an odd

number of teams. This works by providing a by for each team, in a way to compensate for an odd

number of teams. Ideally an even number of teams would be inputted, however this might not always be

the case, as a result this principle was included in Fixtures Generator+ allowing the user to input an oddnumber of teams and still expect the same number of fixtures as if there were n+1 teams (where n is the

amount of teams submitted).

Fixturelist.com (http://www.fixturelist.com 2011) is another example of a tool that allows the generation

of fixtures based on a users input. It is aimed at amateur sports leagues and allows the creation of user

accounts granting the ability to save and edit fixtures produced by the tool. This is built using PHP.

Unlike the bluebones example the outputted fixtures appear to be generated at random (i.e. not using a

predetermined algorithm). To test this, the same inputs were entered into the tool and when submitted,

several different outputs were given. In terms of comparison with the bluebones tool this is slightly more

complex, especially when inputting teams (each team needs a name for example) and the added features

such as being able to register and save a users fixtures. Like bluebones the tool does lack a concept of

distance and regulations that may need to be taken into account by the end user.

2.02 Discussion of Algorithms


12/137


12

At the core of this project is the successful creation of an algorithm or algorithms that can fulfill the

requirements set in the Requirements Specification. In some ways this was the hardest part of the project

and required much research Wang et al. (1997) address a similar problem to one faced by this project

when discussing communication between nodes in a computer network. They use the real world example

of people at a dance party wanting to dance with each other once and only once in the smallest amount of

dances, (metaphor for two nodes communicating), and examine algorithms that can be used to calculate

this. They looked at three possible algorithms, Search algorithm, the Divide and Conquer algorithm and

Graph Theory. The Search algorithm works by looking through the list with regards to i and determining

the first participant found (k) that has not previously danced with i, and subsequently allocating a dance

between the two. If k cannot be found however, i sits out the dance. This is repeated for all participants

until every participant has completed a dance with all other participants. The Divide and Conquer

algorithm works by splitting up the participants into two groups where dances are set up between the

participants of each group that have not already danced with each other. This is repeated until every

participant has danced with one and other.

Wang et al. concluded that both the Search and the Divide and Conquer algorithms could produce an

optimal fixture set for certain values of n, but for other values it would produce suboptimal fixture sets.

For instance, the Search algorithm could produce n-1 (7) fixture sets when n=8, yet when n=6 the

algorithm would produce n+1 fixture sets (7), as a result teams would have to sit out two gameweeks

each. Similarly the Divide and Conquer algorithm could produce optimal (n-1) fixture sets when nequalled a power of 2 (2,4,8,16,32) yet for other values it produced n or n+1 fixture sets. Graph Theory

proved far better and it provides a rather significant advantage over rival techniques in that is guarantees,

for a finite number of teams, complete coverage and perfect matching of teams for the smallest (optimal)

schedule set. This means that if there are n teams, the algorithm will deliver a single set of fixtures in n-1

moves, e.g. if there are 20 teams there will be 19 gameweeks.

Graph Theory 1-factorisation is the process of connecting n amount of nodes using the smallest amount of

connections by doing so creating a complete graph. In his 1969 works Graph Theory (1969), the widely

regarded mathematician Frank Harary devised the following formula to determine the factors, or stages,

needed to create a complete graph.

Fi = {(v0vi+1)} {(vi+j+1vi!j+1) | j = 1, ..., n ! 1},

The theory can be shown diagrammatically together with adapting Hararys formula to a real world

context. Assume there are eight teams (n=8) of any discipline: Team0, Team1, Team2Team7. All

teams must play each other once in seven sets of fixtures (seven gameweeks). Below, the teams are


13/137


! 13

represented in a graph of K8 size as separate nodes. Each fixture is represented by a link between two

nodes.

fig 1. Teams Shown Diagrammatically Using a Graph

Using Hararys equation and setting i=0 first iteration for the first iteration.

F0 = {(v0,vi+1)} {(vi+j+1,vi!j+1) | j = 1, ..., n ! 1},

The first fixture therefore is (v0,v0+1) which equals (0, 1) or Team0 vs. Team1. The second fixture

(v0+1+1,v0!1+1) = (v2,v7) which equals (2,7) or Team2 vs. Team7. J is incremented by 1 now and every

subsequent time a fixture is decided. The third fixture (v 0+2+1,v0!2+1) = (v3,v6) which equals (3,6) orTeam3

vs. Team6. The fourth and final fixture in this set (or gameweek) is (v0+3+1,v0!3+1) = (v4,v5) which equals

(2,7) orTeam4 vs. Team5. Giving a set of fixtures of:


14/137


14

Team0 vs. Team1 Team2 vs. Team7 Team3 vs. Team6 Team4 vs. Team5

Each fixture is show on the graph by a link or edge between the relevant nodes.

fig 2. First Set of fixtures


15/137


! 15

fig 3. Addition of Second Set of Fixtures

This was repeated this time with i=1. Giving the fixtures:



16/137


16

fig 4. Addition of Third Set of Fixtures

i=2.



17/137


! 17

fig 5. Addition of Fourth Set of Fixtures

i=3



18/137


18

fig 6. Addition of Fifth Set of Fixturesi=4



19/137


! 19

fig 7. Addition of Sixth Set of Fixtures

i = 5



20/137


20

fig 8. Addition of Seventh and Final Set of Fixtures, Completing the Fixtures List

i=6


It is worth noting that this algorithmic only produces (n/2)*(n-1) i.e. one team only plays each other once,

generally teams play each other twice (home and away), this can be solved by mirroring the fixtures

produced by the algorithm.

It is worth noting however that this, nor any other method found will produce a set of fixtures that will

ensure every team plays an alternating sequence of home and away games throughout the season. Graph


21/137


! 21

Theory can be used to produce fixtures where the majority of teams will play this sequence throughout

the season but as a result of the very nature of home and away fixtures, each team will have to play

congruent home or away fixtures one point in the season (twice if mirrored). From analysis of the recently

released Premier League fixtures, it is clear that the creators of the list also face this problem.

The Berger Pairing Algorithm as used by the bluebones fixtures generator would provide similar results

but the lack of empirical analysis with larger values of n and scarcity of academic theory associated with

the method meant that Graph Theory1-factorisation using Hararys equation was chosen as the algorithm

used to generate the fixtures.

Another disadvantage of the Berger Pairing Algorithm also has no natural pairing between teams, which

the Graph Theory does, meaning that if the end user required Team0 and Team5 to never play at home at

the same time (due to high numbers of policing that would be required), the Graph Theory algorithm can

be manipulated to force this. For example if there are 20 teams, it was found that if Team 1 was to play at

home in a gameweek, Team 11 would be away, likewise, Team 2 was paired with Team 12 so Team 2

would be at home whenever Team 12 was away and vice versa. This worked for all amounts of teams (n)

and can be expressed as each team below (n/2) having a paired team of i + (n/2) where i is the team ID.

Finally another natural advantage of using Graph Theory to generate the fixtures is that each gameweek

has a pair. One of the requirements of the Premier League fixtures generation is that if a team plays awayon Boxing Day they must play at home on New Years Day. Like when pairing teams it was found that

gameweeks too have a pair, all teams that play at home in gameweek 1 were found to play away in

gameweek 11, likewise all those that play away in gameweek 2, play away in gameweek 12. This natural

pairing of teams and gameweeks allows the manipulation of the fixtures in order to conform to any rules

the end user wishes to enforce on the generation of fixtures and made Graph Theory the obvious choice of

algorithm to use.

2.03 The Software Engineering ProcessIt was decided that a program capable of delivering a set of fixtures between a set of teams on specified

days was to be produced using traditional Software Engineering techniques. Pressman (2010) provides a

detailed look at the Software Engineering process from start to finish. The works suggest the use of a

process model or paradigm, which provides stability, control and organization (Pressman 2010) to the

software engineering process. One such model that Pressman describes is the Evolutionary Prototyping

Model, a model which although is commonly combined with other process models, can be used as a


22/137


22

stand-alone process. Pressman suggests this is to be used in projects when the developer may be unsure

of the efficiency of an algorithm, which was certainly the case during the outset of this project and is the

main reason why this process model was chosen.

Once the process model was decided, traditional Software Engineering techniques indicate that the

creation of requirements is the first step. Requirements gathering and indeed engineering is covered in

much depth by Bray (2002), in which he admits that this process is a hard subject to which there is no

formulaic approach. Pressman reiterates that understanding requirements of a problem is among the

most difficult tasks that face a software engineer (Pressman 2010), stating that it is a good idea to

formally outline the requirements of the end product at a level that can be understood by the client in

order to reduce the possibility that the customers idea of what they want is different from the developers

ideas of what they are producing. A Requirement Specification template provided by Wiegers (2003) was

used to help structure the requirements in a readable and accessible format for the client.

The choice of language and type of platform the program would use was a difficult one to make.

Traditionally programs would function on a stand-alone desktop or laptop computer, however with the

rise of smartphones and the increasing power of the Internet either a mobile app or online tools were

considered. A mobile application was ruled out due to the difficulty inputting and displaying large

amounts of data on a smartphone and also the issue with processing power on such a small device. An

Internet tool built using a language such as PHP would mean the user would not have to download anysoftware, however it would be inaccessible if the user was not able to connect to the Internet, as a result it

was decided to create a traditional application.

C++ and Java were looked at in order to see which language was to be used for this. Both languages are

similar both evolving from C, with Java being the newer technology having only been conceived in 1991

by a group of Sun Microsystems employees (Horstmann 2006). Horstmann (2006) states that part of the

reason why Java has grown so rapidly as a programming language is that it is very similar to C++, its

closet rival. Horstmann also states that other advantages of Java are its rich library and its ability to run,

without change, on Windows, Linux, UNIX or Macintosh computers. As the primary computer being

used to program Fixtures Generator+ is a Macintosh, this point was a rather large swaying point for the

reason why Java was chosen. Of course Horstmann (2006) does not neglect to mention the disadvantages

of Java stating that it was not designed for students, making basic programs harder to write and that Java

is quite a large subject and cannot be learnt in one semester due to its vast set of library packages.

The main reason however that Java was chosen was due to the fact that it was the language the

programmer felt most comfortable with and if another less familiar language were chosen, time may have

been needed to learn certain aspects of the language, time which was not readily available. As the


23/137


! 23

programming language being used is Java, several sources of Java knowledge and theory were required.

As well as the ever useful Java API (Oracle 2011) which provided information on object methods and

constructors, books such as Effective Java by Bloch (2010) and Big Java by Horstmann (2006) were used.

Blochs book was revised and updates for Java SE 6 meaning that the most recent and stable Java API.

Testing is a vital part of the developing process; the production of invalid fixtures, which disobey rules

and criteria without explicitly alerting users to this fact, would destroy confidence and make the whole

program invalid. According to Sommerville (2011) test planning is concerned with scheduling and

resourcing of all activities in the testing process, as such a Test Plan conforming to the relevant sections

of the IEEE 829-2008 (IEEE 2008) standard was created before the production of the program began.

Although first published in 1979 Myers (2004) updated work The Art of Testing contains theory that is

still very much relevant to software testing, many years before Java was even conceived and the

exponential rise of technology took hold. In it Myers (2004) states that Testing in the process of

executing program with the intent of finding errors and not the other way round were testing is used to

demonstrate there are no errors present. This misconception of testing is the cause of poor program

testing. Myers covers static testing (walkthroughs, inspections and reviews), the creation and validation

of Test Cases and an expansive chapter regarding unit testing and how this can be achieved. Sommerville

(2011) states that Unit Testing is the process of testing components such as methods or objects. In

essence this type of testing is the lowest level, but is certainly the most important. Sommerville remarks

that testing is time consuming and unit test cases must be chosen effectively meaning that they shouldshow that components must do what they are intended to do and if there are faults, the unit test cases

should show this. Myers (2004) is also keen to point out that testing cannot guarantee the absence of all

errors but indicates that the aim of testing is to reduce the likelihood of errors and increase confidence

and reliability in the program.

2.04 ConclusionsSimilar tools to the one being designed do exist but seem to be quite basic and lack many features that the

planned program could posses. Nonetheless problems such as the user inputting an odd number of teams

appear to be solved by the current solutions and this was taken into account when designing the algorithm

needed by the program.

The algorithm decided on, Graph Theory, provides the coverage needed for fixture generation and also

provides a natural pairing of teams and gameweeks, and as such is ideal for this program. The literature

used help to decide many things such as the development model and the languages used. It also help to


24/137


24

underline the need for a well structured Requirement Specification, Design Plan and Test Plan as well as

the need to plan projects given time constraints.

Less satisfying was the fact that academic work on an empirical measure of fairness in regards to football

fans is lacking, of course as this is a technical project and for the purpose of this dissertation assumptions

can be made that fairness in this context relates to the cost and time of travel for away fans. To ensure

the aim of producing fairer results is satisfied by the end product; during the analysis section of this

dissertation a measure will be created and used to compare the results from the program being produced

and those produced on behalf of the Premier League.


25/137


! 25

CHAPTER THREE:METHODOLOGYThe methodology of this dissertation will be split into three sections, the pre-planning section, which

included software estimation and risk management as well as the planning that was undertaken before the

program was even considered. The second section is the drawing up of the requirements, the design plan

that would help aid a developer in recreating the final program, and finally a test plan. The third and final

section is that of the detail of the implementation, that is; how the program utilised the Evolutionary

Prototyping model.

3.01 Software EstimationProject management is a crucial element in successful software and IT development (Bob Hughes

2009) and as such it would be sensible for a workable, realistic project management plan to be set in place

at the first instance of any project. As no financial constraints have been placed on the project (wages,

overheads etc.) and this is an individual project with no scope for working in a team, the project plan will

concentrate mainly on time constraints relating to a single person.

One of the first stages of planning any software project is that of software estimation (Bob Hughes 2009).

Software estimation is a notoriously difficult concept, especially at the early stages of a project (Bob

Hughes 2009). Hughes highlights several methods of software estimation such as algorithmic models orexpert judgment and analogy estimations whereby an expert or person who has developed a similar

project in the past is consulted to gage their estimation of the software effort. For this project several

methods of estimation where consulted, however the COCOMO II model stood out as being an industry

recognised method of estimation and seemed to be the most accessible model, for these reasons it was

chosen as the method used to gage the scale of the software being produced.

The first stage of the COCOMO (California 2011) estimation model is the establishing of how many lines

of code the software is likely to be. As can be seen this is already a fairly subjective topic. The estimation

of the program being created was drawn up from the techniques highlighted by (Pressman 2010). Use

Case estimation was considered, however this requires historical information of a similar project. It was

therefore estimated, using experience with past programs, that the program would be about 2000 LOC, or

2KLOC. This was an extremely rough estimate but seemed reasonable based on other programs created

by the developer.

Once the estimation of lines of code (size) was created and the final figure of 2000 SLOC or 2 KLOC was

decided upon, this needed to be translated in to effort. The COCOMO II model was used to estimate the


26/137


26

effort needed to create this software. The formula for the COCOMO II model is as follows (Sommerville

2011):

pm = A(size)(sf)

x M.

The COCOMO II scale factor (sf) values (Bob Hughes 2009) were estimated as the following.

Precedence: low (4.96)

Development Flexibility: nominal (3.04)

Architecture/Risk Resolution: high (1.41)

Team Cohesion: Extra High (0.00)

Process Maturity: low (6.24)

To get the overall exponent scale factor these figures are summed, multiplied by 0.01 and added to a

constant of 0.91.

!"#$%#&'&($(")&*&($+"&,&"$(%%#&

&

To calculate M or effort modifier (Bob Hughes 2009) , the perceived effort values were used:

Product Reliability And Complexity: very low (0.60)

Required Reusability: low (0.94)

Platform Difficulty: low (0.87)

Personnel Capability: high (0.83)

Personnel Experience: nominal (1.00)

Facilities Available: high (0.87)

Schedule Pressure: high (1.00)

Using the effort multipliers above gave a value of M as:

0.6 * 0.94 * 0.87 * 0.83 * 1 * 0.87 * 1.00 = 0.35

Finally, using Boehms coefficient (A) that has been used as the COCOMO II model since 2000

(Sommerville 2011), the final equation and the result of this were the following, where pm is person

months:

pm = 2.94 * (2) (1.0665) * 0.35 = 2.15


27/137


! 27

2.15 person months did seem like a rather large amount of time to create the program and would have put

the project in danger of over-running. The estimation of coefficient A according to COCOMO 81 model

for a small project, which the program being developed presumably falls into, was 2.4. Using this figure

gave the following:

pm = 2.4 * (2)(1.0665)

* 0.35 = 1.75

Using the COCOMO 81 coefficient gave an estimation of 1.75 person months. Of course the COCOMO

II superseded the COCOMO 81 model, nonetheless this model does still holds relevance to todays

software estimations and as such must not be discounted. (Sommerville 2011).

Overall the project estimation gave approximately 2 months, however as can be seen from the way this

software estimation was carried out, it is an extremely subjective topic and the more experience the

estimator has with the platform, the more informed the estimation would be.

3.02 Risk Management

It is often said that the only thing certain is uncertainty and that sentiment certainly holds true for

software engineering. Risk management is used to help development teams comprehend and manage

uncertainty that inevitably occurs when creating software. There are several classes of risk such as

business risks (danger of companies going bankrupt, lack of funding etc.), project risks (inaccurate

software estimation, requirements changing etc.) and technical risks (the platform chosen not satisfying

the needs of the project). Sommerville (2011) recommends the drawing up of a table that identifies the

risks to a project, the probability of this risk occurring and the impact it would have if it did occur.

Risk Probability Impact

Size estimate may be

significantly low

60% Catastrophic

Deadlines set not adequate

enough

70% Critical

Developer inexperience 60% Critical

Requirements change 10% Critical

Technology not meeting 20% Marginal


28/137


28

expectations.

Requirements not

understood

30% Critical

fig 9. Risk Management Table

Several of these risks can be dismissed, for example requirements changing was not particularly

prevalent, as this project has no client per se and thus although requirements may change organically due

to time constraints it was unlikely that they would as the results of a clients demands. Of course, as this

program is loosely aimed at football bodies, a change in rules or regulations by football bodies may cause

requirement modifications. Similarly, technology not meeting expectations also is unlikely. Java is a

highly versatile and flexible programming platform (Horstmann 2006) that can encompass an endless

amount of programs with a infinities scope for types of programs that can be developed, as a result of this

and, the knowledge of the platform gained through previous projects built using Java, meant that the

program being built is considered very feasible.

The inexperience of the developer may have slowed down the project but this was taken into account

when calculating software estimation. Likewise this inexperience may have caused errors, however with

the use of adequate testing these errors could be minimised. Using an IDE such as eclipse that can helpinexperienced users to visually identify syntactic errors also helped to minimise these errors.

It can be deduced that the greatest risk to this project was not completing the program, either due to the

deadlines being set during the planning stage not being adequate or the software estimation techniques

used are found to be inaccurate. Hughes (2009) notes that a report published in 2003 by the Standish

Group found that 82% of projects were late. The statistics certainly indicate that programs are invariable

late and as a result this should be taken into consideration throughout the project.

The drawing up of risks and recognition of them during the development process was vital. There are

three strategies to manage risk (Sommerville 2011):

1) Avoidance a strategy whereby the probability of the risk occurring is reduced2) Minimisation - a strategy whereby the impact of the risk occurring is reduced3) Contingency a strategy whereby the developer is prepared for a risk and has a plan in place to deal

with it.

Sommerville (2011) suggests the drawing up of strategies for each risk that has been identified.


29/137


! 29

Risk Strategy

Size estimate may be

significantly low

Minimisation: Prioritise and develop features in order of priority.

This strategy means that if the program is not developed

Deadlines set not adequate

enough

Minimisation: Flexible deadlines for each prototype.

Developer inexperience Avoidance: Use of literature and Java API to aid knowledge and sue

of well defined testing strategy and IDE that identify syntax for

errors.

Requirements change Unavoidable but not likely.

Technology not meeting

expectations.

Avoidance: Minimisation of third party components and their

impact on the program.

Requirements not

understood

Avoidance: creation of requirements specification.

fig 10. Risk Management Strategy

3.03 Project PlanningAfter software estimation and risk management were carried out and identified a Gantt chart was created

in order to help give a visual representation of a project plan in regards to time. As already discussed the

evolutionary prototyping model was chosen to be the process used for this project. For the purpose of

simplicity and ease of application it was assumed that the model would be split into four iterations of

which equal effort is assumed. The resulting Gantt chart can be seen in fig 11.


30/137


30

fig 11. Gantt chart plan for project management


31/137


! 31

A textual output based on the plan was also produced for reference

-./0& 12.32&4.25& 4.6/&27&879:;525&

?3595@2&1:58?A?8.2?7@& (+B(CBD(""& E&

45/?F@&G;.@& "HB(CBD(""& E&I?3/2&J253.2?7@&7A&G372726:5&!")& "CB(CBD(""& E&

KL.;>.2?7@&.@M&-5/2?@F&7A&G372726:5&!")& D"B(CBD(""& "&

.2?7@&7A&I?@.;&G372726:5& "CB(NBD(""& E&

As can be seen from the above chart, the first section of the pre-development stage was to be the creation

of a requirements specification, with the plan stating it would take 4 days. A requirements specification is

a document thats purpose is to give a detailed description of the software to be built. The document is a

high-level plan designed to be targeted at a client to ensure the clients idea of the final program is the

same as the developers, as such technical terms should be kept to a minimum.

The second stage of pre-development was a lower-level Design Plan. This plan is a set of instructions to

the programmer, as such technical terms were used throughout, a class diagram were used to help explain

the structure of the final program. Whereas the requirements specification should answer the question

what is being delivered, the design plan should answer how it is being delivered. Both sets of pre-

development documents are vital in creating a program and aid both parties to ensure the final project istimely and meets the specification set at instantiation. Looking at previous design plans and experience in

creating these documents in the past it was estimated that this would take four days to complete.

The third step was the creation of a first prototype. Each prototype will expand on the previous one,

adding more and more criteria and functions. This is discussed in more depth during the design section of

this document, but the outline proposal was as follows:

1) The first iteration was planned to be the creation of a program with a basic GUI that would allowthe user to either add teams (name only) manually or via the user of an open teams file function


32/137


32

which. The most basic form of the Graph Theory algorithm is used and mirrored to form the

second part of the season. The output of the fixtures is in a text-based format in a text field area.

2) The second iteration would allow the expansion of the information that users can associate with ateam, such as location via longitudinal and latitudinal co-ordinates. Users will now have the

ability to generate gameweeks via a Generate Gameweek function that generates (n-1)*2

gameweeks.

3) The third iteration would the inclusion of leagues program, allowing users to specify the leaguesin which the team is placed into. In terms of the algorithm this would be expanded to take

distanced into account when generation the fixtures. The GUI would also be expanded to give a

visual representation of the gameweeks, rather than a text based output.

4) The final iteration would be the final program and the one released should there be a client or aplatform for this program. Added functions in this iteration include the ability to save team files

and export fixtures list to either an html or a text file. If there is time available then database

connectivity to allow the saving of fixtures could be implemented and the creation of an events

and request system whereby users can specified certain stipulations on certain days (e.g. Team A

cannot play today, or no fixtures to take play within 30 miles of this location today)

After each of the four iterations there was refinement stage, this was meant the updating of the

Requirements Specification and/or the Design Plan, if this is needed. And, unlike the evolutionary

prototype model discussed in Pressman (Pressman 2010), at the end of each cycle a small amount oftesting will take place. This is for two reasons:

1) To reduce the amount of testing at the completion of the program.

2) To ensure all rules required by that cycle are being adhered to.

.


33/137


! 33

3.04 Requirements EngineeringThis Requirement Specification is a total description of the characteristics, function and behavior of

Fixtures Generator+, the program to be created. In essence the aim of this is to ensure that the clients

concept of the Fixture Generator+ is the same as the designers. This requirements specification follows

the template, where applicable, created by Wiegers (2003).

This document is intended for use both by the client and the developer but the technical level of the

document will be aimed at all abilities. When the document uses technical diagrams an adequate level of

description will be used in order to help understanding. The rest of this document contains a description

of the functional and non-functional requirements of Fixtures Generator+, including a brief description of

the proposed graphical user interface of the final program.

The reader is suggested to read the overview sections and the sections that are most pertinent to the

subject that they are hoping to learn from the document. Any terms specific to this program are defined in

the glossary section, in the appendix. Suggested background reading for this document include (Pressman

2010) and (Sommerville 2011) which cover many of the Software Engineering principles mentioned

throughout. UML diagrams are covered thoroughly by (Alhir 2003) and (Muller 1997).

1) System Descriptiona) User Classes and Characteristics

Users will need to be moderately competent with computing in order to be able to use the program. No

technical qualifications will be needed but a basic understanding of opening, and saving files will be

required. As no installation is warranted users must be able to transfer the program to their computer and

be able to launch it. All users will be able to refer to the User Manual that will be aimed at users with

moderate computing experience.

b) Developing EnvironmentThe software will be written in the Helios Service Release 2 Eclipse IDE (Build id: 20110301-1815)

environment for Java Developers, complied using Java 1.6 JDK. In terms of the hardware platform used,

the program will be built using a 2.4GHz Intel Core 2 Duo Macintosh computer running Mac OS X

10.6.8 with 4GB of RAM.


34/137


34

c) User DocumentationA user manual will be produced to help the end user navigate through the program and eventually create a

set of fixtures based on their criteria. A PDF version of this manual will be accessible from the program

itself. As well as this, in-program help and guidance such message boxes and instruction labels will be

provided. Ideally the program should be intuitive enough to be used with a minimal amount of help

however it will be provided for those end users that need it.

d) AssumptionsIt can be assumed that teams must play at a most two consecutive home or away games at some point

during the season, this is due to the fact it would be impossible to generate a set of fixtures without some

teams playing consecutive games at either their home venue or at away venues.

There must be k(n-1) gameweeks per season (where k is either 1, 2 or 4 and n is the number of teams).

Per gameweek there must be n/2 fixtures with two teams per fixture, a home team and an away team. It is

assumed that the away team has a set of travelling fans that travel to the home teams venue and the home

teams fans do not travel at all.

A gameweek must consist of at least one day, although it can consist of up to seven. Over these day(s)

there must be n/2 match slots in which the fixtures will be placed into by the generator. Each match slot

has a time and a fairness rating between 1 and n/2, which is used by the generator to determine whichslots to place the fixtures into. The user can input this rating during the Gameweek Generation process.

For example a user defined match slot with a rating of 1 will receive the fixture with the greater distances

for that gameweek. 10 (where n=20) will receive the fixture with the least distance.

A user can pair a team to another team. A pairing of teams is where if team A is at home then team B is

away. This can be useful for police and transport authorities as two teams playing in the same gameweek

in the same city can bring difficulties to both sets of authorities. Similarly a user can set rival teams, this

is different from a pairing as they might be geographically far away but might have a history of policing

trouble between them, for example Leeds and Millwall have a history of violence between rival fans

despite being 200 miles away, as too do Liverpool and Manchester United fans. A match slot can be

stipulated as not allowing fixtures in which rivals play each other, for example the Premier League

restricts all high policing games on Boxing Day ad New Years Day, as police simply do not have the

personnel to look after the games on those days.

We can make the assumption that fairness is in essences the distance travelled between the away teams

venue and the home teams and it can be assumed that all fans from the away team travel from the away

teams venue, in the real world this would not happen, the majority of fans may live near their team but


35/137


! 35

not travel from the ground and some fans may live all over the country. The distance between the venues

can be calculated as the crow flies. This means that the user must input the longitudinal and latitudinal

co-ordinates of the teams position and the distance between the two can be calculated between these

venues. In real world terms this will be different from the actual distance as roads rarely go in a straight

line from point A to B but examination of the calculated distance compared to the distance given by a

online map service such as Google Maps may reveal a constant that can be used to equalise the different

values.

e) DependenciesJavas built in JComponents lack an intuitive way of inputting dates. Without third party components the

user would have to enter their desired date textually, this is quite an inefficient method, thus a solution

was sought to provide the user with a graphical method on inputting a date. JCalender (Toedter 2011) is athird-party Java component that can be imported into Java for use with other programs being written.

Granted, it is not a vital component but it adds to the usability of the program. No other third-party

components will be used, as the default Java library is substantial enough to deal with the requirements of

the program.

2) System Features

fig 12. Use Cases of Program

The above Use Case UML demonstrates the features that the user will have available to them on the

launch of the program. To start the user (Actor: Fixtures Creator) will either have the choice of opening a

team file or manually adding teams. Once these teams are entered into the program, by either method, the

user must generate gameweeks. This is achieved by use of a wizard that takes users preference for the

amount of gameweeks and their structure, such as the amount of days and fixtures per gameweek. Once

the user has decided on the format of their gameweeks they can select Generate from the final wizard


36/137


36

screen which will create the gameweeks and display them graphically (discussed in the User Interfaces

section).

Only when the program has a valid set of teams and a valid set of gameweeks can the fixtures be

generated. This is achieved by displaying another wizard that allows the user to input their criteria for the

fixtures list. Once the user is happy with the criteria they can Generate Fixtures which will cause the

program to look a the teams, the gameweeks specified and the criteria the user has selected and try to

create a set of fixtures to satisfy all parts of the request. If the generator finds no possible fixtures set it

will alert the user to this fact, however if a fixture list is possible it will display it graphically. Finally the

user will have an option of saving these fixtures to either a text file or a HTML file to be read by an

external actor. This actor could be a fixtures body, or the teams/competitors involved in the competition.

Each feature is given a priority and rating for cost and benefit of the feature. A cost in terms of the

project is the estimated amount of time each feature would take to implement, in some aspects this relates

to the COCOMO II model already discussed with an estimate of the lines of code needed to implement

the function and its perceived complexity. A benefit is the perceived benefit to the end user in terms of

functionality or usability, such that those with high benefits would save the user time and effort in

creating a fixtures list. The benefits are subjective and have little empirical backing. Priority is rated by

how well the program would function without the feature; again this is a subjective measure.

i) Open Teams FileDescription and Priority

This allows the user to open a pre-made file that can be read by the program to save the time and

effort of inputting individual teams into the program. The file will take the extension of .fgp

(Fixtures Generator Plus).

Priority Benefit Cost

High High Medium

Stimulus/Response Sequences

User clicks either an Open icon (depicted using traditional open folder image) or uses the menu

system described in the User Interface section and selects Open Team File. This launches an Open

File Dialog box where the user selects their .fgp file from their system. Once selected the teamswill be displayed in the GUI as a list.


37/137


! 37

Functional Requirements

1.1 REQ: Allow the user to open a file that contains a list of teams and their details.

1.2 REQ: Alerts the user if the file is corrupted or in an invalid format using a message

box.

1.2 REQ: Displays teams in GUI as a list.

ii) Add TeamsDescription and Priority

This allows the user to add a singular team to the team list of the currently selected league.


Very High High Low


User can select this function by selecting the Add Team icon (as depicted by a plus symbol image)

or by using the menu system described in the User Interface section and selecting Add Team. An

Add Team form is displayed allowing the user to input the teams name, co-ordinates and

selecting, if needed, their rival and paired teams using list boxes. An OK button can be used

when the user is satisfied their input, which is then added to the list of teams associated with the

currently displayed league.


2.1 REQ: Allow the user to add a team to a league and its:

2.1a REQ: Name

2.1b REQ: Co-ordinates

2.1c REQ: Rival Teams

2.1d REQ: Paired Teams

iii) Save Teams File


38/137


38

Description and Priority

This allows the user to save a team list and their details to a file with the extension .fgp. The file

can then be processed by the Open Teams File function. This feature can help reduce the time and

effort of inputting individual teams into the program.


Medium High Medium


User clicks either a Save icon (depicted using traditional floppy disk image) or uses the menu

system described in the User Interface section and selects Save Teams. This launches a Save File

Dialog box where the user inputs a name and destination for their .fgp file.


3.1 REQ: Allow the user to save a list of teams and their details that the user has created.

iv) Edit TeamDescription and Priority

Allows the user to edit an already inputted teams details.


Medium Medium Low


The user can select the team from the team list (as shown in the User Interface section of this

document) by clicking on the required teams name. Once the user has clicked the team name an

Edit Team form will be displayed in which the user can edit all the teams details. An OK

button is used to confirm the users changes.


4.1 REQ: Allow the user to edit a team and its:

4.1a REQ: Name

4.1b REQ: Co-ordinates


39/137


! 39

4.1c REQ: Rival Teams

4.1d REQ: Paired Teams

v) Delete TeamDescription and Priority

Allows the user to delete a team from the team list.


High High Medium


The user can select the team from the team list (as shown in the User Interface section of this

document) by clicking on the required teams name. Once the user has clicked the team name an

Edit Team form will be displayed with a checkbox stating Delete Team. To delete the selected

team the user checks the box and clicks ok, a dialog box is displayed asking for confirmation, if

the user confirms the team disappears from the team list.


5.1 REQ: Confirm user wants to delete selected team

5.2 REQ: Delete selected team.

vi) Generate GameweeksDescription and Priority

Creates a set of gameweeks based on various user requirements such as:

1) Amount of gameweeks (as multiple of (n-1)).2) The date of the first gameweek.3) The interval between ease.4) How many days per gameweek.5) Define match slots, and their times and fairness rating per day.


40/137


40

Once the user has specified their requirements the gameweeks are generated and displayed in the

scroll pane (as described by the User Interface section of this document) of the GUI.


High High Very High


User can click either a Generate Gameweek icon (depicted using calendar image) or use the

menu system described in the User Interface section and selects the Generate Gameweeks option.

This launches a Generate Gameweeks Wizard that will allow the user to specify their requirements

for the generation of gameweeks.


6.1 REQ: Allow the user to specify:

6.1a REQ: Amount of gameweeks (as multiple of (n-1)).

6.1b REQ: The date of the first gameweek.

6.1c REQ: The interval between weeks.

6.1d REQ: How many days per gameweek.

6.1e REQ: Define the match slots, and their times, per day.

6.2 REQ: Generate gameweeks based off users specification.

6.3 REQ: Displays gameweeks graphically.

vii) Specify CriteriaDescription and Priority

Allows the user to specify the rules and criteria that the fixtures generated by the program must

adhere to. These options include:

1) Paired teams cannot play at home in same gameweek. Default: false. 2) Set maximum amount of weeks a team can play consecutive home or away matches.

Default: 2.

3) Set gameweek with minimum distance. Default: none.


41/137


! 41


Medium High High


User clicks an option either by using an icon button (denoted by a cog image) or via the menu

system discussed in the User Interfaces section of this document, selecting the option Generate

Gameweeks. Program outputs the fixtures list it has generated via the GUI.


7.1 REQ: Allow the user to specify whether paired teams can play at home in the same

gameweek.

7.2 REQ: Allow the user to specify the maximum amount of weeks a team can play

consecutive home or away fixtures.

7.3 REQ: Allow the user to specify a gameweek, if required, that has the least possible

distance between team venues.

viii) Generate FixturesDescription and Priority

Takes the teams entered into the system and the gameweeks generated by the user using their

specification and creates a set of fixtures which are displayed using the GUI but can be saved as a

HTML webpage or a plain-text document. If the user has specified criteria that the program cannot

find a solution to, an alert is displayed to the end user explaining this and suggesting the removal

of some of these stipulations. This is the keystone of the program and should be treated as the

priority.


Vital High Very High


User clicks an option either by using an icon button (denoted by a cog image) or via the menu

system discussed in the User Interfaces section of this document, selecting the option Generate

Gameweeks. Once the user has specified their criteria for the fixtures they can generate the

fixtures by pressing a Generate Fixtures button. The program will then output the fixtures list it

has generated via the GUI.


42/137


42


8.1 REQ: Generates fixtures based on user requirements

8.2 REQ: Alert the user if a possible combination of fixtures is not found.

8.3 REQ: Output fixtures list to GUI.

ix) Export FixturesDescription and Priority

Allows the user to export the fixtures produced in one of two formats 1) a HTML table 2)

plaintext.


Medium Medium Low


Once the fixtures have been generated the user has a previously disabled function available to

them via the menu system as described in the User Interface section of this document. This

function will open a Save File Dialog that will allow the user to select their format (default will be

plaintext) and choose a name and location for their file to be saved.


9.1 REQ: Allow the user to export the fixtures generated as either a HTML or plain text

file.


43/137


! 43

3) External Interface Requirementsa) User Interfaces

a. Main FrameThe program will be christened Fixtures Generator+ and below is the expected layout of the main screen

that encompasses a lot of the features defined by the System Features section of this document. This

MainGUI will be the first screen that welcomes the user to the program and will be the launch pad to its

features.

fig 13. Mock-up of MainGUI

The MainGUI can be thought of containing two separate parts. 1 and 2 can be considered the input

sections, this is where the user can either choose to issue commands to the program in two ways:

1) A menu system in which the user can click the text to reveal a sub menu of available functions.2) A icon system in which visual prompts denoted by icons such as a floppy disk to save a teams

file, or a cog to generate the fixtures are used. Users click on the desired icon to execute a

command.

The second part, denoted by 3 & 4 is predominantly the output section of the program. 3 is a list of teams

into the system contained in a list box. This can be filled by the Open Teams File feature (adding multiple

teams at once) or via the Add Team feature that adds a singular team via a separate Add Team form

(discussed later).


44/137


44

The final part, denoted by 4 in the above diagram, is the gameweek window. This is a horizontal and

vertical scrolled pane that contains a visual representation of the gameweeks once the user has generated

the gameweeks using Generate Gameweeks. Once the user has generated their fixtures using Generate

Fixtures, these too will be displayed in the pane.

b. Add TeamThe add team form is used to input a team and its details into the system. These details include its name,

GPS co-ordinates and its rival and paired teams, if applicable. A mock-up of this can be seen below:

fig 14. Mock-up of Add Team Window

The only required text field to contain text before the team can be added is the Teams name; all other

fields could be left blank.

c. Edit TeamVery similar to the Add Team form is the Edit Team form. This is almost identical to the Add Team form

however it does contain some differences, mainly that the OK button changes the details of the selected

team, rather than adding a new instance. Users can also select the delete team option that will remove the

team from the team list. A warning dialog asking for confirmation will be displayed to ensure the user

wants to remove the team.


45/137


! 45

fig 15. Mock-up of Edit Team Windowd. Generate Gameweeks

The Generate Gameweeks wizard form contains three separate frames allowing user to specify their

requirements for the generation of gameweeks. The first frame asks the user to specify three criteria for

the gameweek generation:

1) How many times they wish teams to play each other. Giving the options of once, twice and fourtimes.

2) The amount of days between each gameweek. Default is 7.3) The start date of the first gameweek. Users can will be able to the calendar component to choose

the date if wanted.


46/137


46

fig 16. Mock-up of first window in Generate Gameweek wizard

As can be seen the first new options will be selectable via combo boxes but the third option will utilise

the JCalender discussed in the dependencies section of this document. Using this option will allow the

user to click the button and see a visual calendar in which they can use to select a date.

Once the user is content with their specifications they can select the next button, displaying the second

frame. This second frame will ask the user to expand further on their criteria for gameweek generation. A

draft of this can be seen below:

fig 17. Mock-up of second window in Generate Gameweek wizard


47/137


! 47

The user will have the choice of selecting which days the fixtures are played on, the time of the fixture

and the fairness rating where by 1 will indicate that it is easier to travel at that than 2 and so on. The

generators will user this information later when deciding fixtures giving precedence to fixtures with a

greater distance. The user select whether a fixture between rivals can be played during this match slot.

Once the user has inputted their criteria they will select generate. The wizard will then close and the

empty gameweeks will be shown visually in the gameweek pane, depicted by 4 in the MainGUI diagram.

e. Generate Fixtures

The user can now select Generate Fixtures from either the drop down menu (1) or the icon menu (2). The

resulting dialog box can be seen below:

fig 18. Mock-up Generate Fixtures Window

This gives the user three criteria in which they can choose for the generator to take into account whendeciding the fixtures. Once they are satisfied with their choices that can click the Generate button that

will force the generator to set the fixtures and output them into section 4 of the MainGUI.

b) Hardware InterfacesAs with most traditional programs such as this, the main two hardware interfaces will be a mouse and a

keyboard. Primarily a mouse should be used but keyboard interaction such as using shortcuts (e.g.

CTRL+C for copying text) and navigational commands (e.g. ALT to access menu options) will be

integrated into the program.


48/137


48

4) Nonfunctional Requirementsa) Performance Requirements

The program should use a minimal amount of time to generate its fixtures list. The program will take no

more than 2 seconds per team that is inputted. For example if 24 teams are entered, the program should

take no more than 48 seconds. This requirement was selected for the reason it seems an acceptable

amount of time for the generation of fixtures. The system used by Atos can take several minutes to

complete its fixture generation (Fletcher 2009), which given our criteria of 2 seconds be per team would

take this program 184 second, or just over three minutes. Thus our criteria keeps the program inline with

similar programs. This is a strict requirement yet it is very achievable. Ideally the figure would be less

than 1 second per team.

It is unlikely that, given the minimum hardware requirements already stated, that processing power will

be an issue however testing of the generation of fixtures should be carried to ensure processing

constraints are not an issue.

b) Safety RequirementsUsers have the ability to save teams and leagues in a .fgp file, it is their responsibility to ensure this file is

not lost or corrupted but it is the responsibility of the program to ensure that teams and leagues are saved

using this extension effectively. This must be ensured during the testing stage. Once fixture lists have

been generated it is the users responsibility to save these in a specified format (HTML or text).

c) Security RequirementsThere are no security requirements in regards to this program. Perhaps the inclusion of user authentication

could be implement at a later stage as part of an extension to the program, but at present the costs of this

inclusion far outweigh the benefit to the end user.

d) Software Quality AttributesThe program must work on Windows, Mac OS and Linux operating systems. In terms of the ease of

portability of the program, the file size must be kept under 2MB for ease of downloading the program

from an email or the Internet. The program must be reliable and always available in that is will always

work when required and due to this requirement it must have no reliance on the Internet during use.

The program must produce correct fixtures, in keeping with the users criteria and if no solution is found

then it must notify the user of this. It must also be adaptable for every type of league where fixtures need

to be produced.


49/137


! 49

5) Other RequirementsFrom a legal point it is worth bearing in mind the copyright implications of using team names and official

trademarks. With this in mind all user documentation and in-program text and images must not infringe

on these. Similarly the Premier Leagues fixture list for current seasons is copyrighted and as such must

not be reproduced.

6) Other Issues

Database integration may not be possible in the timeframe however should there be time available then

this may be included allowing users to save fixtures so they can be loaded at another date. Another issue

is a formula to calculate the distances between two co-ordinates must be sought and tested.


50/137


50

3.05 Design Model(a) Architecture

The architecture of the program is vital and due care and consideration was taken in regards to this. The

architecture of software is the overall structure of the software and the ways in which that structure

provides conceptual integrity for a system (Shaw and Garlan 1994). It was decided that an object-

orientated architecture would be used to help structure the modules in this software.

fig 19. Object Oriented Architecture (Fitzgerald and Riddle 2011)

This architectural structure contains modules with their own variables and operations that are user to

interact with these variables. Interaction between modules is achieved by using operation provided by

other modules.

Due thought was taken to avoid a rather monolithic structure given that such a structure cannot easily be

grasped by a software engineer (Pressman 2010) and the inverse of this, modularity is the single

attribute of a software that allows a program to be intellectually manageable (Myers 1978). In short it is

often easier to break down problems into smaller sub problems, this is called dividing and ruling. For

these reasons the structure of the program was decided to be quite modular, however this brings its own

problems in that the more modular a program becomes the greatest the cost (in terms of time) to integrate

the modules. Conversely the more modules there are in a program, the lesser the cost per module. This

gives a U shaped curve to the total cost to the software. Pressman demonstrates this phenomenon

graphically, seen below:


51/137


! 51

fig 20. Modularity costs (Pressman 2010)

The region M is the optimal amount of modules that will give the least cost compared with the benefits

from the modularity. It was therefore taken into consideration especially given the time constraints faced

by this project.

Another characteristic to be taken into account is that of information hiding, this is the concept that each

modules processes should be of no concern to another module. That is to say that every module should

be able to operate with no prior knowledge of its algorithms and data. This information hiding helps

modularity that, in turn, aids developers in testing and debugging as well as future software development

or maintenance.

Similar to modularity is the concept of functional independence; this is the process of creating modules

with a rigid function and a minimization in interaction with other modules (Pressman 2010). This means

that module A and module B must have a clear and defined role and keep within that role, it also means

that although module A and module B can interact with each other, these interactions must be kept to a

minimum. Coupling is the idea of interconnectivity between modules, the less interaction modules have

between each others code, the greater the functional independence is said to be. Similarly cohesion is

how well a module performs a single well-defined task. The greater the cohesion a module displays, the

greater the functional independence (Pressman 2010).

With all these considerations in mind a UML model was drawn up and for the program, this can be seen

in fig 21. Careful consideration was taken when designing how objects communicate with each other.


52/137


52

fig 21. UML Class Diagram of program


53/137


! 53

(i) Team (public class)

This module represents a team such as a football team or a rugby team etc., however a team could also be

used to represent a singular competitor in events such as a tennis league or a chess league. A team

consists of a name, co-ordinates (a custom class holding the longitude and latitude co-ordinates of the

teams venue, this is discussed later), the teams paired teams and the teams rival teams.

(ii) Coordinates (public class)Note: This should be called co-ordinate but as Java will not accept a hyphen in the name of classes it

was decided that Coordinates would be used.

This is a module that represents the geographical longitudinal and latitudinal co-ordinates of a location

that can be used by the Team class to identify the teams venue and can be used by the generator to

calculate the distance between two venues.

(iii) League (public class)This module is essentially a wrapper for an array list of Teams. Fixtures are generated from a league via

the Generator.

(iv) Fixture (public class)The Fixture class holds two Teams, a home team and an away team. The Generator is responsible for

creating the fixtures and calculating the distances between the two teams. Once the generator creates a

Team it is assigned to a MatchSlot via the addFixture function of the Gameweek class which determines

which slot to associate with which fixture.

(v) Gameweek (public class)This module acts as a wrapper class for a Day and encapsulates the Days components. A Gameweek can

contain one or more Days and holds a list of Days in an array list. A Gameweek can be identified by its

ID attribute. It can be created using its constructor that takes an int as its ID and a GameweekTemplate

that helps to establish the structure (how many days etc.) that gameweek will take.

(vi) Day (public class)The Day object is in essence a wrapper class for MatchSlots and holds one or more of these slots in an

array list.


54/137


54

(i) MatchSlot (public class)The MatchSlot is essentially an empty Fixture and is used by the Gameweeks addFixture operator to

assign Fixtures to MatchSlots.

(ii) GameweekTemplateA gameweek template is used by the Gameweek Generator to constructor a new gameweek with the

specification outlined by the GameweekTemplate. Its constructor takes an array list of Days with

MatchSlots and a start date specified by the user in the Gameweek Generator Wizard. Its only function is

one to increase the dates inside the away

(b) Graphical User Interface Design(i) MainGUI

As with all windows inside Java, the MainGUI (seen in fig 13) is encased inside a JFrame. The JFrame

has a border layout (Oracle 2011) and contains three JPanels: menuPanel, sidePanel and centrePanel. The

menuPanel is given the location of PAGE_START inside the JFrame, the sidePanel is set to

LINE_START and centrePanel is given the location CENTER. An outline of the planned position of the

panels can be seen in fig 22.

fig 22. Layout Plan of MainGUI

1) menuPanel

JMenu

menuPanel

sidePanelcentrePanel


55/137

A Fixtu

dissertation - a fixtures solution

Documents