AE1DBI-CW2: UNNC Staff Football
Organisation Website
Introduction
Each Wednesday, staff members here at the University of Nottingham Ningbo join on the
artificial pitch (on campus) to play football (‘Soccer’ for our American friends) against
one-another. Organising the match can take considerable effort, requiring the scheduling
and consultation of many people in order for a match to go ahead. For example, some
people change their minds, and can no longer attend, despite originally saying they could.
Currently, the staff football is organised entirely by email and calendar invitations. Whilst this
works, it is not without issues or limitations.
The Staff Football Management Team (SFMT) have asked you to develop a web-based,
Match Management System (MMS) to aid in the organisation of future football events for the
staff team. The SFMT have asked you to build a website that will, at a minimum, provide the
following functionality:
A. Allow players to sign-up/sign-in and register to attend particular games
B. List all upcoming games, available spaces and whether a user has registered to
attend a given event
C. Allow the SFMT (as an administrative user) to add, edit and delete games as
necessary
To develop this MMS, you must apply all the skills and knowledge that you have acquired
throughout the DBI course. The SFMT need the system to be completed by the end of the
next month, which means you have until:
4pm on Monday, the 24th of April.
No late submissions will be accepted.
The submission requirements are detailed below (in this task sheet). Failure to submit on time will
result in a mark of 0 (zero). This assessment contributes 25% towards the overall module grade.
Your submission will be marked on the school’s cs-linux server. Subsequently your code must work
on the PHP and MySQL installations on cs-linux. “It works on my machine” is not a valid argument
when questioning your grade for this assessment.
Core Functionality
Below, we provide the minimum, core functionality, that you are expected provide in the
delivery of the MMS. You must use this specification to develop the functionality of the
system. You may apply your own judgement to any detail that is not precisely specified
below.
“The website must allow users to sign-up and sign-in/login to the system. A
user will have a name, telephone number and email address. There is no
current requirement for users to be able to update their details, but you may
add this functionality if you wish. There are 2 types of users – Players and
Administrators. When a user initially signs-up to the website, they should be
considered “Players”.
The MMS allow Administrators to create Matches. An match consists of a
starting time, duration, date, description/information, location and the
maximum number of players (capacity). A player may register to attend an
event only if there is an available space. A player can sign up to play a
particular game precisely once. That is, a player can not register for the same
game more than once. A player may play in many different matches.
Administrative users may also register to play games. Administrative users
should be able to see all events on a single page (that is only accessible to
administrative users) and have the option to CRUD a match:
● Create – Create/Specify new matches
● Read – View existing available matches
● Update – View and modify the details of an existing match
● Delete – Delete an existing match
A player should be able to see all current/future events and register to attend
an event. A player should not be able to see matches that have already
occurred or transpired (do not show past events). The website should indicate
if a player is already registered to play in a particular game. If a game has no
spaces available – this fact should be indicated in the user interface and the
user should be prevented from registering for that match. There should also
be the option for players to un-register from a particular game that they are
already registered to attend.
A player should not be able to register for a game if they are not signed-in or
registered to the MMS. A player should not be able to CRUD a game – this
functionality should only be available to Administrators. ”
Additional Features
In addition to the core functionality specified above, you may want to add additional features
and functionality to your implementation. You are free here to express yourself on a
technical or creative level in this coursework. Remember, you need to document any
additional features you implement via the reference document, which is described below.
IMPORTANT NOTE: You are NOT required to implement any/all of the features specified
below. These are suggestions for possible additional features. Check the marking scheme
for guidance on how the inclusion of additional features may affect your grading. Remember
a good ‘core-only’ implementation will be marked favourably in comparison to a poor/ok ‘core
+ extra features’ implementation. Focus on having a reliable and functioning core, before
considering adding new/additional features.
Possible additional functionality includes:
● The ability for Administrators to allocate players into teams for a particular game
● The ability for Administrators to remove already registered players
● The ability for Players to specify a preferred position (Goalkeeper, Defender,
Midfielder or Striker) on the field – both in general and for a particular game
● An attendance page for administrators to keep track of player attendance
● A page for keeping track of game/player statistics e.g. top scorer, average goals
scored per game etc
● The ability for user’s to upload images from the match
● You are free to implement any other (relevant) feature
Technological Requirements
The website and it’s information must be written using the technologies presented during the
course of this lecture.
● MySQL - Should be used to store the information used in this system (Users,
Matches and any other data required to run your implemented MMS).
● PHP - Should be used to authenticate users and manage the data being used in the
system.
● HTML - Should be used used to specify the structure of the interface (the website)
and it’s data that users interact with.
● CSS – Should be used to inform the styling and aesthetic appearance of the MMS.
● Javascript – Should be used for client-side validation and dynamic updates of the
website(if necessary) e.g. AJAX.
Third party libraries can be used, but must be fully open source whose licence allows for
use in a commercial/enterprise setting. You must detail any third party libraries used in the
reference document (detailed below).
Your system must be deployed and operational on the school’s cs-linux server. You may not
use external, third party hosting providers.
You should test your final website on a variety of different browsers, but should ensure it
displays well on the latest version of Google Chrome. There is no requirement for this
coursework to render well on a mobile device, only a desktop environment. Your MMS
should function and appear as desired on the university’s desktop machines found in
SEB-306.
Your system will be tested in the latest version of Google Chrome on a monitor with a
resolution greater than (or equal to) 1366×768.
Submission
There are 3 deliverables for this project. Incomplete or incorrect submissions will be subject
to a 25% penalty.
Source Code for the System
You are required to submit a ZIP archive containing all the source materials
necessary for deploying the UNNC event system. This must be entirely your own
work (with the notable exception of third party libraries or images – which must have
the appropriate attribution in the Reference document (below)). Your ZIP should be
named:
zyXXXXX.zip
Where zyXXXXX is your university provided username.
Operational System
Your system must be live and operational on your personal webspace on cs-linux.
You may not use an external, third party hosting provider. Specifically, your system
must be available from the following url:
http://cs-linux/~zyXXXXX/MMS/
Where zyXXXXX is your university provided username. Note: I have not specified a
precise document within the MMS directory. To allow the webserver to operate in this
manner you should name your homepage either: index.html or index.php, depending
on how you have chosen to implement your MMS.
Reference Document
The purpose of the reference document is to protect you from the implications of
plagiarism rather than to diminish the impact of your submission. Remember, you
may not simply copy and paste other peoples work (code, written words, images,
anything!), but you may utilise their approach or technique towards solving a
problem.
Your reference document should be in PDF format and named:
zyXXXXX.pdf
Where zyXXXXX is your university provided username.
Below is a detail of what you should include in your reference document.
http://cs-linux/MMS/
● Brief MMS usage explanation/walkthrough:
○ Because there are a few different approaches to implementing this
system (especially in the implementation of administrative users), you
need to include an explanation of how to use the system under these
specific circumstances.
○ Note: I do not want a user manual. If your explanation is more than 1
page in length – then something is wrong, either in the design of your
system or in the documentation of it. I would expect explanations to be
half a page in general.
○ Example
■ “In order to sign in as an administrative user, use the following
username and passwords in the login screen on the homepage
…. ”
● Any additional features that you have implemented as a part of your MMS.
● Third Party Sources of Information – Websites or books you have used in
developing your MMS. Students with less than 5 references will be penalised
in the marking of CW2.
○ Example Reference: “To develop the user interface and styling of the
website I used the CSS guidelines specified by http://cssguidelin.es/ ”
● Third Party Libraries – You are free to use third party libraries such as
BootStrap, jQuery or Angular, but you must ensure they are Open Source
and you must detail them and their licence type in this reference document.
Again, students who use libraries without documenting their usage will be
penalised in the the marking of CW2.
○ Example Reference: “In this system I utilised the open source
Javascript library jQuery (https://jquery.com/) which is released under
the terms of the MIT license.”
● An increasingly important part of project development is the correct citation of
images. For this project, you must use images that are either:
○ Licenced under the Creative Common Public Attribution CC BY or
ShareAlike CC BY-SA
■ Details – https://creativecommons.org/licenses/
○ Anything published on the Nottingham University website
https://creativecommons.org/licenses/
http://cssguidelin.es/
https://angularjs.org/
https://jquery.com/
http://getbootstrap.com/
Notes
Here are some general notes/warnings regarding the coursework. (Note – this might get
updated during the coursework period as new questions/observations come in.)
● Be careful with PHP versions, cs-linux runs a particularly old (PHP 5.3.3) version of
PHP. Ensure that any language features or libraries you use are compatible with the
installed version of PHP. No updates or software installation will be performed. The
reasons for this were explained in lecture – this is not something we are able to
control.
● Sometimes debugging PHP can be problematic since, by default, it does not provide
us with error messages or run-time errors. To enable these errors, try adding the
following 2 lines to the top of your PHP script:
error_reporting(E_ALL);
ini_set(‘display_errors’, 1);
● For MySQL, build tables within the database you have been using during labs. Be
careful with software versions again – but this affects MySQL a lot less than PHP
(see above point).
● Test, test, test! Getting a system like this to work correctly and as expected requires
a significant amount of testing, be it automated or manual.
● Validation. Remember what you were taught in class, validate both on the client and
server side. Security and data integrity is a key aspect of web based systems.
Ensure that your application correctly handles any input data from users.