Research

Existing Solutions

Previous Projects

``An Automated Sports Centre Booking System'' [#!pearse!#] is a project with a similar aim to this one, was done only two years previously, and achieved a first classification. ``Automated Booking And Enquiry System For A Sports Club'' [#!salmon!#] is slightly different, in that the system was designed for an external sports club, though many of the design issues faced are likely to be similar to this project. For these reasons, these two projects are likely to be a very important source of information for this project.

User Requirements

There are three types of requirements to be considered: Functional, Quality, and Resource [#!hughes_cot!#, page 13]. None of the requirements listed here are resource requirements, because such requirements relate to the time taken to deliver a project, or the financial cost. As this is a student project, and therefore has no cost and a non-negotiable deadline, there are no resource requirements listed here, and they will not be discussed any further. Any requirements listed in this chapter will either be flagged as $\framebox{\bf func}$ or $\framebox{\bf qual}$ , indicating a functional or quality requirement, respectively.

Sports Centre Staff

To gain some insight into what the current booking system is, how it worked, and what would be required from an online system, a number of meetings with Bill Butterworth, the manager of the Sports Centre, were arranged. Many useful points were made in these meetings.

A number of students have attempted similar projects to this one, without success. The main problem experienced by previous students was not realising how difficult a booking system of this scale would be to create.
A booking system just for the sunbeds and/or squash courts should be attempted first, since these venues are much simpler to model, having a one-one mapping between activity and venue. This is in contrast to sports halls, which support many activities, and in some cases, different activities at the same time, as shown in Figure (page ).

In addition to these points, various user requirements were obtained. Few of these were obtained in the first meeting; most were obtained later when Mr Butterworth had seen the system, and had the opportunity to see what was not implemented completely, or correctly. These are in addition to the minimum requirements and objectives -- it was suggested that these should be considered optional extras rather than requirements, since the overall requirement of building a working system is the most important goal.

Speed. $\framebox{\bf qual}$ The current booking system is very quick for the staff, since it is simply based around two sheets of A3 paper per day, and Mr Butterworth suggested that the equivalent information on a computer screen would require at least four screens of information. It quickly became apparent that the main problem to overcome in this project is making the computer system as fast and easy for the staff as the current paper based system.
Support for periodic bookings. $\framebox{\bf func}$ A periodic booking is one which is fixed at the same time every week. These are used to book a number of squash courts every week for the squash society, for example.
Restrictions on number of bookings. $\framebox{\bf func}$ At present, the reception staff will not permit users to make large numbers of bookings. For example, a user would not be permitted to book a sports hall for four hours of basketball. As this is a free activity for sports members, some users may be tempted to do this.
While implementing such a restriction appears to be trivial, it becomes more complex when four friends decide to do this, each booking a single one hour slot. An online system cannot easily prevent this, while the reception staff may become suspicious if four consecutive bookings are made within a few minutes.
It was suggested that in such situations, human intervention will be required at some stage.
Printable booking sheets. $\framebox{\bf func}$ These would be useful for ticking off booked sessions as people arrive. Rather than mark each booking ``attended'' as people arrive, it might be easier to tick off the bookings on a printed sheet, and then update the database at the end of the day, or during quiet periods of the day.
More personal information. It was suggested that with an online system, more personal information could be stored, either for convenience or health and safety reasons. Such information may include:
- Emergency contact information. Such information would only be necessary for members of the public, since the University's central database stores this information for staff and students.
- Skin type. This could be used to limit the number of sun tanning sessions a user may book. In fact, people with skin type 1 may not use the sunbeds in the Sports Centre at all.
More control over periodic bookings. $\framebox{\bf func}$ At the time this requirement was mentioned, periodic bookings were already partially implemented.
However, it became apparent that it was necessary to either associate date ranges with these bookings, or to have two sets for term-time and non-term-time bookings.
It may also be necessary to cancel individual bookings. For example, many bookings at weekends are for particular events, which may or may not take place on any given weekend. It should be possible to cancel such events for a specific day, rather than completely cancelling them.
Periodic restrictions. $\framebox{\bf func}$ It should be necessary to allow specification of time slots where no specific booking is made, but where any bookings made must be for a predefined set of activities. For example, there are some time slots where the only permitted activity in a Sports Hall is badminton.

As well as the meetings with the manager, the reception staff also provided some contributions relating to possible features.

$\framebox{\bf qual}$ Two specific points related to ease of use were mentioned, including the possibility of a bar-code reader for student cards, and possibly a touch-screen system for making bookings.

At present there is a problem with people making bookings and then not subsequently arriving; this problem occurs most for the activities that are free with a sports membership card, such as badminton and soccer. $\framebox{\bf func}$ It is clear that an online system could easily send emails to users who frequently did this. Alternatively, it could fine them, suspend their accounts for a short period, or another similar action.

Students

The following requirements were gained from fellow students, when asked what they would like to see from an online booking system.

Easy to use $\framebox{\bf qual}$
Booking anything -- Gym, etc. $\framebox{\bf func}$
Discount for booking online
Booking consecutive/concurrent slots This would allow users to easily book concurrent or consecutive sessions of a particular activity, without having to book all sessions individually.
Regular sessions Allow users to book the same slot every week or every day.
Online Help System $\framebox{\bf qual}$
Database of numbers/photos A database containing the username and a photograph for each member would remove the requirement to bring some identification (for example, student card) when booking sessions.
Personalised Adverts or Links For example, when a user logs in, if they play squash frequently, the system could pop up a link to a page of information about the squash society, etc.
Advice about sports A page or so of information about each sport, for people not familiar with a particular sport.
Live information $\framebox{\bf func}$ For example, show how many people are currently in the gym. Some people may prefer to use the gym while it is quiet, this feature would avoid people having to make a (potentially long) journey to the gym, only to find it crowded or full.

System Architecture

As the title of this project implies, the decision to implement the system as a website was made from the start.

In fact, there are very few alternatives. By the nature of the system, it must use some sort of client/server architecture, since a single, centralised database is required. Alternative architectures, along with reasons for not using them, are discussed below.

Custom client/server applications. In this architecture, a custom application would be developed for both the client and server sides of the system. There are many reasons why such an approach was not taken:
- Users would have to install the software on their machines, and keep it up-to-date as new features were added, or bugs fixed.
- The author has no experience of writing software for Microsoft Windows. As this is the platform the average Sports Centre user will almost certainly use, either at home or on an ISS machine, this would be the platform of choice.
- With this architecture, much more user interface code would be necessary, as with a website, the web browser handles most of this -- the server side application must simply generate the HTML code to represent form elements, and so on.
- Much more code would also be required on both sides of the system, to handle the network connection. With a website, this is handled automatically on both the client and server side, by the web browser and web server, respectively.
Command line system, using telnet. An example of a system using this architecture is the library catalogue available by using telnet to connect to lib.leeds.ac.uk. Although the author believes that command line systems can be a useful and efficient interface, it was felt that most users do not, and even the author would probably find a command line interface to this system quite cumbersome.

As well as being the only viable choice, the website architecture was chosen because the author has extensive experience of developing active websites.

This means the system will be a typical three-tier architecture:

Data layer: MySQL
Business layer: The PHP scripts which comprise the active part of the website, and which are interpreted by the PHP module of the Apache web server software.
Presentation layer: The user's web browser, which may be anything the user chooses (for example, Microsoft Internet Explorer or Konqueror).

Sections , , and will explain the reasons for choosing each of the technologies mentioned here.

Database Management System (DBMS)

Microsoft SQL Server and Oracle were not considered because they are both proprietary systems, and the author personally prefers free and open source software. This is both to reduce the cost of the system, and to make development easier since no expensive software is required to develop the system at home.

The two most prominent open source DBMS packages are PostgreSQL and MySQL PostgreSQL provides more advanced features, such as transactions and foreign keys. However, MySQL offers higher performance. [#!dbms_compare!#]

The choice for DBMS was quite straightforward -- the MySQL system was chosen. As well as providing better performance than PostgreSQL, the author is very familiar with it, and it is used by the web hosting company on which the system was hosted during the development cycle.

The MySQL DBMS provides everything this project is ever likely to need, and it is felt that the author's extensive experience with MySQL outweighs any slight advantages a more advanced DBMS might bring. One particular problem is the lack of support for referential integrity on standard table types; however, this is not seen as a major problem provided the business layer is careful in the way it uses the database. This is especially true with this system as there is only one application available to access the database. Referential integrity is most useful when there are multiple applications accessing the database, when custom applications are written to do a specific task, or when users may execute arbitrary SQL queries against the database. [#!sar_per_comm!#]

Programming Language

The choice for implementation language was slightly more difficult. Initially Perl CGI scripts were considered, as the author is very familiar with the Perl programming language, and also with writing CGI scripts in Perl. Perl is also free and open source.

Other possible languages, such as ASP and Cold Fusion, were not used because they are both proprietary systems, and this system is being created using free and open source software as far as possible. Also, JSP (Java server pages) was not used because of the author's personal dislike of the Java programming language. It was felt that the language provides nothing significantly better than PHP, so it would not be sensible to use a language the author does not like, unless there was a good reason to do so.

However, the final decision was to use PHP. The author only has a small amount of experience with this language, but it was chosen for a number of reasons:

The language is quite similar to Perl in some ways
Knowledge of this language may be useful in the future
It is a more modern technology than Perl CGI scripts
Accessing many different DBMS packages is possible, and easy, using PHP
It places less load on the server, since PHP is interpreted by the HTTP daemon, whereas CGI scripts generally require a separate process to be created

The primary references for PHP will be [#!phpmysql!#] and [#!phpnet!#].

Web Server

The choice of web server is largely irrelevant to this project, provided it supports the PHP language.

In practice, it is almost certain that the Apache web server will be used, due to it being free, open source, and the most popular web server on the Internet [#!netcraft_survey!#].

Next: Design Up: A Web-Based Sports Centre Previous: Introduction Contents