1. DUBLIN INSTITUTE OF TECHNOLOGY
KEVIN STREET
SCHOOL OF COMPUTING
TIMETABLING SYSTEM
FOR EDUCATIONAL INSTITUTIONS
PROJECT MANUAL
MICHAL DABSKI
C11717071
DT211-4
2014-2015
PROJECT SUPERVISOR: MICHAEL COLLINS
2. Timetabling System Page | II
Abstract
Schools around the world are using outdated systems for scheduling and providing students with
timetables. Those systems are often complicated and difficult to use. In today's fast paced world of
smartphones, tablets and laptops users expect everything to be an app and be fast. This is why it's
important that a modern, better system be developed.
This project's aim is to develop a timetabling system which can replace systems currently used by
educational institutions. It will design and build a completely new system from the ground up that
conforms to the standards of the modern web development, by using modern technologies and
techniques.
The project is a web based system developed with Django framework as well as front-end technologies
like jQuery, AngularJS and Twitter Bootstrap. It uses a Postgres database to store data and exposes
JSON API by using Tastypie library. It integrates with existing timetabling systems like DIT and FET
by parsing data in HTML and CSV formats. The project also implements student attendance tracking by
utilizing Google Cloud Messaging and Bluetooth technologies.
3. Timetabling System Page | III
Declaration
I hereby declare that the work described in this dissertation is, except where otherwise stated, entirely
my own work and has not been submitted as an exercise for a degree at any other university.
Michal Dabski
4. Timetabling System Page | IV
Acknowledgements
I would like to thank my supervisor Dr. Michael Collins for the guidance and advice throughout this
project.
In addition I would also like to thank Dr Bryan Duggan who has motivated me since my first year at
DIT and helped me realise my potential.
Finally I would like to thank my girlfriend Paulina for the support and motivation given and help with
testing of the finished product.
8. Timetabling System Page | VIII
7.3 Conclusion....................................................................................................................... 99
8 References .............................................................................................................................100
9 Appendix ...............................................................................................................................102
9. Timetabling System Page | IX
TABLE OF FIGURES
Figure 1.1 Project's Gantt Chart. The task numbers correspond to tasks listed in Table 1.1. .................... 5
Figure 2.1 What school do you attend ........................................................................................................ 9
Figure 2.2 How do you usually check your timetable ................................................................................ 9
Figure 2.3 What devices do you bring to school?..................................................................................... 10
Figure 2.4 How often do you check your timetable.................................................................................. 11
Figure 2.5 How does your school provide timetables............................................................................... 12
Figure 2.6 How often does your timetable change ................................................................................... 12
Figure 2.7 Is the web timetable mobile friendly....................................................................................... 13
Figure 2.8 FET user interface ................................................................................................................... 15
Figure 2.9 aSc Timetables 2015 presents a more user-friendly interface................................................. 16
Figure 2.10 CMIS form for selecting timetable........................................................................................ 17
Figure 3.1 Django Model declaration for Institution................................................................................ 21
Figure 3.2 Institution Table generated by Django for SQLite.................................................................. 21
Figure 3.3 Travis CI shows progress of public builds .............................................................................. 28
Figure 4.1 Use case diagram of the system............................................................................................... 30
Figure 4.2 Timetable view........................................................................................................................ 33
Figure 4.3 Timetable displayed on a mobile device ................................................................................. 34
Figure 4.4 System architecture ................................................................................................................. 35
Figure 5.1 setupdatabase.sh script responsible for creating and populating database for development
environment .............................................................................................................................................. 41
Figure 5.2 Django admin configuration class........................................................................................... 42
Figure 5.3 Home page of the system shows participating institutions ..................................................... 42
Figure 5.4 Course selection page.............................................................................................................. 43
Figure 5.5 Revisited implementation of group selection.......................................................................... 44
Figure 5.6 Institution Admin panel........................................................................................................... 47
Figure 5.7 Flow of data in synchronization logic ..................................................................................... 48
Figure 5.8 Flowchart demonstrates the logic behind timetable synchronization...................................... 50
Figure 5.9 Course Resource declaration ................................................................................................... 52
Figure 5.10 JSON representation of a Course object................................................................................ 53
Figure 5.11 Mobile login response ........................................................................................................... 54
Figure 5.12 Diagram of the attendance functionality ............................................................................... 56
Figure 5.13 Event Attendance model (class methods omitted) ................................................................ 57
Figure 5.14 Student attendance entry model (class methods omitted) ..................................................... 58
Figure 5.15 User interface for taking attendance in the Android application. The application shows the
lecturer the attendance rate. ...................................................................................................................... 60
Figure 5.16 Example of an attendance object sent from Teacher's device ............................................... 60
10. Timetabling System Page | X
Figure 5.17 A sample JSON of Attendance report posted by the student's application to the Attendance
API............................................................................................................................................................ 61
Figure 5.18 The student receives a notification that their attendance has been recorded......................... 62
Figure 5.19 Implementation of event attendance queryset ....................................................................... 64
Figure 5.20 Attendance details in the institution admin dashboard.......................................................... 65
Figure 5.21 Users can easily download current timetable as a PDF document by selecting PDF from the
Download dropdown................................................................................................................................. 66
Figure 5.22 Apache configuration for the Django website....................................................................... 70
Figure 5.23 Interface for importing and exporting data in CSV format. .................................................. 72
Figure 5.24 Timetable events can be filtered by selecting student's group and subject from dropdown . 74
Figure 5.25 Main JavaScript logic responsible for hiding unselected events. It is responsible for reading
selected items, hiding events, and saving the selections as browser cookies. .......................................... 75
Figure 5.26 Android Studio was the IDE used to develop the android application.................................. 76
Figure 5.27 The Android application displays a subtle notification with room number on student's
wearable device......................................................................................................................................... 77
Figure 5.28 Student can swipe up notification on the wearable device to see more details about current
or upcoming timetable event..................................................................................................................... 78
Figure 6.1 Varnish stat command reports that 1950 requests out of 2138 were server from cache......... 85
Figure 6.2 Statistics of Varnish cache test................................................................................................ 85
Figure 6.3 Circumventing Chrome's email validation by editing the html source of the document ........ 87
Figure 6.4 Cross Site Request Forgery attempt using curl. A CSRF token was passed, but Django
detected that the request was malicious. Sed command is used to strip HTML tags from the output. .... 88
Figure 6.5 PyCharm displays test results after running all tests............................................................... 90
Figure 6.6 Testing REST filtering ............................................................................................................ 91
Figure 6.7 Subset of attendance unit tests................................................................................................. 92
Figure 6.8 Simple parser test, asserts that each field in the input data is parsed into exact expected value
................................................................................................................................................................... 93
Figure 6.9 Testing that parser doesn't create duplicate teacher object if teacher already exists in the
database..................................................................................................................................................... 94
Figure 6.10 Testing importing most commonly accessed timetables....................................................... 95
Figure 9.1 CMIS ePortal displays timetable........................................................................................... 102
Figure 9.2 CMIS presents timetable in a grid format ............................................................................. 102
Figure 9.3 CMIS ePortal on a mobile device.......................................................................................... 103
Figure 9.4 CMIS ePortal forces user into small frame ........................................................................... 103
Figure 9.5 Timetable generated by FET ................................................................................................. 104
Figure 9.6 PyCharm IDE ........................................................................................................................ 104
Figure 9.7 Django built-in admin panel.................................................................................................. 105
Figure 9.8 Database ERD diagram ......................................................................................................... 106
Figure 9.9 Institution Details form.......................................................................................................... 107
11. Timetabling System Page | XI
Figure 9.10 Campus and Room management......................................................................................... 107
Figure 9.11 Timetable management page............................................................................................... 108
Figure 9.12 iPhone application developed by DT228/2 student Timothy Barnard uses the API exposed
by this system.......................................................................................................................................... 109
Figure 9.13 The android application displays notification to student showing progress of detecting their
attendance ............................................................................................................................................... 109
Figure 9.14 Institution Administrators have access to the overview of the attendance.......................... 110
12. Timetabling System Page | XII
TABLE OF TABLES
Table 1.1 Project timeline........................................................................................................................... 4
Table 4.1 Database tables, their corresponding models and purpose ....................................................... 39
Table 6.1 Time for user to access their timetable ..................................................................................... 80
Table 6.2 Functional test results ............................................................................................................... 83
13. Timetabling System Page | 1
1 INTRODUCTION
1.1 INTRODUCTION
A timetable is a table that allocates students, teachers and rooms into time-bound events. Timetabling
software is a program used by educational institutions to manage timetables for rooms, teachers and
students. Such software is often a computer program that generates and exports timetable as static
HTML document which is later published on institution's website.
The system described in this manual is timetabling software targeted for educational institutions like
Schools and Colleges. It will allow Students and Teachers to view their timetables via web interface, and
institution administration to manage the institution details and timetables using the web admin panel.
1.2 BACKGROUND
In the earlier days, before computers, class scheduling was performed by a person and displayed in
school hall for students to see. Later, the job of creating the timetable was taken over by more efficient
computers. In the last two decades, thanks to the progress of technology and the Internet becoming more
common, the timetables would be published for students on the school website. Nowadays, timetabling
software is very efficient at scheduling events, but it appears that there is still potential for improvement
in serving the timetables to user in a way that is efficient and easy to use.
1.3 PROJECT REQUIREMENTS
The finished project should meet the following functional requirements:
Support multiple institutions
The system should house timetables for multiple institutions
User accounts
Users should be able to log in. There should be different types of accounts for Students,
Teachers, and Institution administrators with appropriate privileges.
View timetables
Students should be able to view their timetables on the website as well as using a native Android
application and be able to filter out irrelevant modules and subgroups from the view.
14. Timetabling System Page | 2
Receive notifications about upcoming events
The system should notify students about upcoming timetable events and offer helpful
information (i.e. room number, name of the subject and start time).
Manage timetables
Institution administrators should be able to manage Institution resources and timetables via
online panel.
Import and synchronize timetable from existing system
Institution administrators should be able to import existing timetable from external source and
automatically update if changes are detected.
Notify users of change in their timetables
The system should send notification to the mobile app whenever a change has been made to
student's timetable.
Record student attendance
The system should allow teacher to take attendance using the mobile application.
Synchronize timetable with Google calendar
Students should be able to export their timetable to Google Calendar.
Download timetable
User should be able to download timetable for offline viewing.
Timetable generation
The system should allow administrator to automatically generate timetable.
Non-functional requirements:
Security
The system should implement protection against common threats, like SQL injection, cross site
scripting, and cross site request forgery. It should also protect against data loss by performing
regular off-site backups.
Usability
The system should meet Nielsen's Heuristics principles and implement responsive layout for
mobile users.
Performance
The system should respond quickly to http requests, utilize cache to improve speed.
15. Timetabling System Page | 3
1.4 AIM & OBJECTIVES
The aim of this project is to develop a fully featured web based system that allows students and teachers
to view their timetables and register student attendance.
In order to achieve this aim, it has been split into smaller, more manageable objectives:
Research existing systems
Research relevant technologies
Design the system
Develop website for viewing student timetables
Implement user login and registration
Develop control panel for institution administration
Implement timetable management in institution management panel
Implement REST API for mobile applications
Update existing android application
Implement DIT timetable import and synchronization
Implement timetable event notifications in the android app
Integrate with Google Calendar
Integrate Google Cloud Messaging for push notifications
Implement teacher timetable view
Integrate Varnish HTTP accelerator
Develop attendance taking system
Implement push messages for institution users
Implement timetable change notifications
Implement timetable event filtering
Develop timetable generation
16. Timetabling System Page | 4
1.5 PROJECT TIMELINE
Agile software development methodology has been selected for developing of this project. The
objectives listed in chapter 1.4 have been split into 7 time-bound sprints of two weeks each in order to
improve time management. Table 1.1 outlines the project plan.
ID Task Name Start Finish
1Sprint 1 Mon 20/10/14 Mon 03/11/14
2 Research existing systems Mon 20/10/14 Sat 25/10/14
3 Research technologies Sat 25/10/14 Tue 28/10/14
4 System design Tue 28/10/14 Fri 31/10/14
5 Implement web interface Fri 31/10/14 Mon 03/11/14
6Sprint 2 Tue 04/11/14 Tue 18/11/14
7 Implement user types and login Tue 04/11/14 Thu 06/11/14
8 Implement institution admin panel Thu 06/11/14 Sat 15/11/14
9Sprint 3 Tue 09/12/14 Tue 23/12/14
10 Implement timetable management Tue 09/12/14 Sat 13/12/14
11Sprint 4 Wed 21/01/15 Tue 03/02/15
12 Implement API for mobile app Wed 21/01/15 Thu 22/01/15
13 Update Android app Thu 22/01/15 Sat 24/01/15
14 Implement timetable import and sync Thu 29/01/15 Sat 31/01/15
15Sprint 5 Wed 04/02/15 Tue 17/02/15
16 Implement notification for upcoming lecture Wed 04/02/15 Thu 05/02/15
17 Implement sync with Google Calendar Sat 07/02/15 Sat 07/02/15
18 Integrate Varnish Mon 09/02/15 Tue 10/02/15
19 Teacher timetable view Wed 11/02/15 Fri 13/02/15
20 Integrate Google Cloud messaging Sat 14/02/15 Sat 14/02/15
21Sprint 6 Wed 18/02/15 Tue 03/03/15
22 Push messages Sat 21/02/15 Sat 21/02/15
23 Push timetable on change Sun 22/02/15 Sun 22/02/15
24 Implement attendance taking Sat 28/02/15 Sun 01/03/15
25Sprint 7 Wed 04/03/15 Wed 18/03/15
26 Implement timetable generation Sat 07/03/15 Sat 07/03/15
27 Timetable filtering Sun 08/03/15 Sun 08/03/15
28 Testing Sat 14/03/15 Tue 17/03/15
TABLE 1.1 PROJECT TIMELINE
17. Timetabling System Page | 5
The sprint plan has been designed to ease time management and help determine whether the project is
being developed on time or if it's behind. Each sprint covers on average four tasks. The tasks in total
should take less time than the sprint in order to leave time for debugging in case major problems are
encountered. If the time spent on the tasks within sprint exceed the time allocated for sprint, it is an
indication that the feature being developed in the problem task should be dropped in order to complete
the project on time.
Figure 1.1 shows the Gantt chart of the project. The time between sprints 2 and 3 has been scheduled to
review prior work and designs, and document them in the Interim Report. The time gap between sprints
3 and 4 shows Christmas break and time allocated for exams and study.
FIGURE 1.1 PROJECT'S GANTT CHART. THE TASK NUMBERS CORRESPOND TO TASKS
LISTED IN TABLE 1.1.
18. Timetabling System Page | 6
1.6 WALKTHROUGH OF THE REPORT
The Introduction chapter outlines the high level description of the system as well as background and
planned timeline of the project and methodology. Research of Existing Systems reviews existing
solutions of similar nature used currently by educational institutions and surveys students about their
experience and expectations relating to timetabling systems used by their schools.
19. Timetabling System Page | 7
Research of Relevant Technologies introduces the reader to existing technologies that could potentially
be incorporated into the project.
The Design chapter outlines technical design on the project, considers challenges and possible solutions.
Implementation chapter goes into details of how the system is implemented considering each of the
requirement outlined in the Introduction chapter.
The Testing chapter introduces the reader to the methodologies used for testing of the system, evaluates
the system and demonstrates the test results. The Summary chapter summarizes the document by
reflecting on the work carried out, then considering future changes to the project, and finally concludes
the document.
1.7 CONCLUSION
This chapter introduced the reader to the overall view of the system. It talked about the past methods of
timetabling, introduced the reader to the requirements of the system, as well as methodology used, aims
and objectives, and the timeline of the project. It also walked the reader through the upcoming chapters
of the report.
20. Timetabling System Page | 8
2 RESEARCH OF EXISTING SYSTEMS
2.1 INTRODUCTION
This chapter evaluates existing timetabling systems available online as well as surveys students about
the systems used by the institutions they attend.
2.2 SURVEY
2.2.1 QUESTIONS
A total of 33 students have been surveyed anonymously about existing systems used currently in the
institutions they attend. The survey was published on the forum of Convoy Trucking1
website. The
demographic of the website is people who play computer games, therefore mostly young people, and a
subset of them who are students were asked to answer the survey. The aim of the survey was to learn the
current state of timetable systems being used, how students access their timetables, and what technology
they have access to. The students were asked the following questions:
What school do you attend?
This question aimed to give context as to what types of educational institutions the students attend. The
possible answers were Primary School, Secondary School, College/University, and "Other". None of the
respondents attend Primary School, Most (47%) attends High School, and College or University (41%).
Only 13% chose "Other".
1
http://www.forum.convoytrucking.net/
21. Timetabling System Page | 9
FIGURE 2.1 WHAT SCHOOL DO YOU ATTEND
How do you usually check your timetable?
This question aimed to give an idea of which methods are preferred by users given current options.
Responders could answer multiple of the following options: “On Computer”, “On mobile/smartphone”,
“Own Paper copy”, “Print-out in school hall”, “Ask colleague”, "Other". Multiple choice format was
chosen, because students may have multiple preferred ways of checking their timetable.
Most responders (44%) use their own paper copy of the timetable, but a close 41% use their mobile
phone to check timetable. Less popular options were computer (28%), checking printed copy displayed
in the hall (25%), and asking colleague (22%). 9% of students also use "other" means to check their
timetables, but no details have been provided.
FIGURE 2.2 HOW DO YOU USUALLY CHECK YOUR TIMETABLE
22. Timetabling System Page | 10
What devices do you bring to school?
This is question was designed to find out what electronic devices students have access to while they are
in school or college. Students could pick multiple of the following answers: laptop, tablet, mobile phone,
smartphone, wearable device (smartwatch, and the like). Again, respondents could pick multiple options,
because they are likely to bring multiple electronic devices to school
The largest portion of students (72%) who took part in the survey declared having access to a
smartphone. Other devices were not nearly as popular: laptop 34%, mobile phone 31%, tablet 16%, and
wearable devices 13%, which is surprising, considering how new the wearable technology is.
It appears that vast majority of students nowadays use smartphones, which is not surprising, as they took
over the mobile phone industry in the last years. More surprising is fact that the wearable devices, which
are used by almost as many students as tablets. This shows how common new technology is among
young people.
FIGURE 2.3 WHAT DEVICES DO YOU BRING TO SCHOOL?
How often do you check your timetable?
Answers to this question should give an idea how often the system would be used by student. This is
significant for several reasons: to understand the importance of the proposed system in student's life, and
how reliant they would be on it if it was put in use. Another reason is to get an idea of how heavily the
system would be used traffic-wise as discussed in further chapter 4.3.1. Students were given the
following options: “Once per term/semester”, “once a week”, “Once a day”, “After/before each class”.
Most students declared that to check their timetable once per day (38%). Next, closely followed
23. Timetabling System Page | 11
“After/before each class” (28%), and “once per semester” (25%). Only 9% of students check their
timetable “once per week”.
It is surprising that 25% of students should check the timetable only once per semester as it seems
impossible to memorize the schedule by looking at it just once. It is possible that the question has been
interpreted in two ways: some students check the web timetable only once in semester, and write it down
for later reference instead of coming back to the website. Other students interpreted the question as
intended (i.e. how often they check online or their own copy of the timetable). Another possibility is,
that students who check their timetable only once per semester don't attend their classes, but this does
not seem very likely considering the large number of responses.
FIGURE 2.4 HOW OFTEN DO YOU CHECK YOUR TIMETABLE
How does your school provide timetable?
This question should shed more light on how institutions currently publish their timetables to students.
This is important, because it draws a picture of current state of existing systems. Students could pick
multiple of the following: "Printed copy displayed in the school", "Website", "Mobile app", "E-mail",
"Other". It appears that most institutions display a printed copy (64%), and only about half of them
(58%) uses website. The other answers were not as popular: Mobile app - 9%, E-mail - 6%, and “Other”
6%.
24. Timetabling System Page | 12
FIGURE 2.5 HOW DOES YOUR SCHOOL PROVIDE TIMETABLES
How often does your timetable change?
Answers to this question should give an idea how often school timetable changes throughout the
semester. This is significant, because in institutions where timetables change more often, students will
also need to access the system more often in order to get updated version of their timetable. It also gives
an idea how often data would be updated within the system. Students could answer one of the following:
“Doesn't change”, “Few times in semester”, “Few times a month”, and “Every week or more often”. For
most students (36%), timetable doesn't change at all, or changes only a few times in a semester (30%).
Only a small portion reported more frequent changes – “Few times a week” (6%), and “Every week or
more often” (6%).
FIGURE 2.6 HOW OFTEN DOES YOUR TIMETABLE CHANGE
Is the web timetable mobile friendly?
As per previous questions, students have access to smartphones and use them to check their timetable.
This question should give an idea of how current systems take advantage of the technology. Students
25. Timetabling System Page | 13
could pick one of the following: "There is no (timetable) website", "No, it's desktop website only", "Yes,
the website looks fine on mobile", "Yes, it's optimized for smartphones", "There's a mobile app". Given
current technology, the perfect answers should be "it's optimized for smartphones", or "There is a mobile
app". However, these answers were selected only by 3% and 6% respectively. For most students there is
no timetable website (39%). Close second was "The website is desktop-only" (24%), and "The website
looks fine on mobile" (24%). This shows that the majority of student's can't use their timetabling system
on mobile, because it doesn't exist, or it's not available for smartphones. Only 24% of students seem
satisfied with how the system looks on their mobile devices despite not being optimized.
FIGURE 2.7 IS THE WEB TIMETABLE MOBILE FRIENDLY
Additional comments
This question was free-form and was optional. It allowed students to enter any comments and wishes
about the timetabling system used by their school. Some users expressed the wish that their institution
provide timetables for mobile devices. Other users complained how complicated their system is to use.
Notably, one response was particularly detailed: "Yes, the timetable should be easy to access- now it
requires going through several tabs on the web and a list of courses->semesters->modules every single
time when you want to view the timetable. It's very difficult to go through the procedure on a
smartphone, unfortunately. So to have a less painful life I usually save it as file somewhere and make it
accessible on my phone. But my solution does not work when from time to time the timetable changes. I
would be so happy if they provide an android app with the timetable". Overall, answers to this question
expressed how unsatisfied students were with the existing systems, because they were either difficult to
use, or not optimized for mobile device. However, this question was optional, so it should be noted that
it was answered mostly by the vocal minority.
26. Timetabling System Page | 14
2.2.2 CONCLUSION
The survey shows that students are technologically advanced, use latest technology like smartphones,
and use them to check their timetables. However, the existing systems do not seem to cater for these
devices and instead most schools provides either no web access to timetables, or access is limited to
computer, which only 34% of students bring to school. Of course, students are likely to have access to
desktop computers in school library, or lab. But perfectly they should be able to use devices that are
immediately available to them, like smartphone. As a result, students resort to printing or writing down
their timetables, which are prone to change multiple times in a semester.
2.3 FET
The first reviewed solution was FET (Free Timetabling Software). It is an open-source program
targeting schools, high schools, and universities. It was written in C++ using Qt, and the source code is
available on the website2
under GNU license.
The software presents rather crude and minimalistic user interface. The menus are almost
exclusively textual with no graphics. But the program is in fact rich in features instruction manuals are
available both offline and online3
. Once institution details, teachers, rooms and groups are added, user
can easily generate the timetable by pressing the generate button. There are also options to customize
timetable and add constraints which will be taken into the equation by the generator.
The program only supports its proprietary xml format for saving and reading timetables, but it
also allows the data to be exported and imported to csv files. The timetables are generated directly into
html format and in order to modify timetable, user needs to update the constraints and generate the
timetable anew. The generated HTML files present tables in a variety of configurations. Some of them
show all events in one big table, some show a list of tables for each group, room or teacher. These
HTML files can be either published on school's website or printed out and displayed in a hall. The
reader is referred to Figure 9.5 of the appendix presenting a HTML view of timetable generated by FET.
2
http://lalescu.ro/liviu/fet/
3
http://timetabling.de/manual/FET-manual.en.html
27. Timetabling System Page | 15
FIGURE 2.8 FET USER INTERFACE
2.4 ASC TIMETABLES 2015
ASc Timetables4
is a considerably more user-friendly than FET. It has a more modern user interface
with graphics and intuitive layout and an interactive tutorial. It also allows user to automatically
generate timetable, make manual changes, and export it to a number of formats. It also allows user to
import timetables from other software, including FET. The timetables generated using aSc can be
exported in HTML format to be published on school's website, or printed out in a number of
configurations.
However, unlike FET, this is not free software. ASc Timetables costs €499 for Standard license, but
cheaper, €399 option is available for elementary schools, as well as more expensive Premium and PRO
versions (€995 and €3995 respectively) are also available for more demanding clients who require
additional options, like per-student scheduling and personal support. There is also a free trial version
available for evaluation.
4
http://asctimetables.com/
28. Timetabling System Page | 16
FIGURE 2.9 ASC TIMETABLES 2015 PRESENTS A MORE USER-FRIENDLY INTERFACE
2.5 CMIS
Advanced Learning's CMIS5
is another timetabling solution for Colleges. Notably, it is used by a
Number of institutions in Dublin, including DIT6
and ITT7
.
CMIS uses a web based ePortal to serve timetables to students. It allows students to log in and view their
personal timetables. However, in institutions that students don't have personal timetables, login is still
required and users are asked to fill out a form as presented in Figure 2.9, where users have to select their
group, and enter week range that they wish to see the timetable for, and after pressing next select format
in which they wish to view the timetable: as a grid or a table. The table view appears to be more user
friendly, while grid is a raw table of data from the database. The reader is referred to Figure 9.1 and
Figure 9.2 of the appendix.
5
http://www.advanced-learning.co.uk/products/cmis/
6
https://www.dit.ie/timetables/
7
http://cmis.ittdublin.ie/eportal/index.jsp
29. Timetabling System Page | 17
FIGURE 2.10 CMIS FORM FOR SELECTING TIMETABLE
As shown in Figure 9.1, timetable in the table view is displayed inside a frameset, which is bad practice
in web development (Nielsen, 1996). The frame used to display timetable is also constant size, meaning
it will not show any more content on a large screen and user is still force to use the scroll bars to
navigate around the timetable, while it’s surrounded by blank space. The reader is referred to Figure 9.4
of the appendix. The ePortal does not seem to be optimized for mobile devices either as demonstrated in
Figure 9.3 of the appendix. The text size is too small for mobile devices, and there is too much of it for a
mobile device.
2.6 CONCLUSION
All of the reviewed timetabling systems have some common features. They are mostly executable
programs that generate the timetable on a PC, which is later exported to the web server where it is
served to students. Having separate systems for generating and serving timetables certainly has its
benefits. Administrators don’t need internet access in order to create or manage the timetable. This
removes the issue with interface lag of a web-based system, as well as security issues.
30. Timetabling System Page | 18
On the other hand, web interfaces implemented in these systems do not seem to adhere to modern
standards of web design, like responsive design. Their design is often very crude (FET), or difficult for
students to use (CMIS).
31. Timetabling System Page | 19
3 RESEARCH OF RELEVANT TECHNOLOGIES
3.1 INTRODUCTION
A number of different technologies for various purposes have been research in order to pick out the ones
that are best suited for this project. As for every web based system, there need to be back-end solution to
implement business logic, database for storing persistent data, as well as front-end presentation layer
including front-end logic and styling. There was also need to decide on the right version control system,
IDE, continuous integration system, and hosting for the deployed system.
3.2 BACK-END
A number of web technologies have been considered for this project. The requirement was for the back
end framework to take care of most of the boilerplate, like database queries and security, so
development efforts could be focused on functional requirements.
3.2.1 PHP
PHP is an interpreted, dynamically typed scripting language targeted at developing dynamic websites. It
was created in 1995 by Rasmus Lerdorf. The name PHP is an acronym meaning Personal Home Page
(PHP: History of PHP - Manual). PHP supports databases since version 2.0 and enables programmers to
work with MySQL, PostgreSQL and other databases. Since version 3.0 PHP also supports object
oriented paradigm.
PHP inherits a lot of features, constructs and syntax from C programming language, but it is higher level
than C, and is usually embedded in html code. This makes it easy for programmers experienced in
similar languages, like C++, Java or JavaScript learn PHP.
It is a widely used scripting language, currently running on 200 million websites (Ide, 31). There is a
large number of popular content management systems and frameworks written in PHP, including
Joomla, Wordpress, Moodle and Drupal, and it is also used by Facebook.
It is easy to set up with Apache on any Linux server thanks to LAMP (Linux, Apache, MySQL & PHP)
stack (Rouse). LAMP is available free of charge and provides developer with a HTTP server (Apache),
32. Timetabling System Page | 20
database (MySQL), and PHP interpreter. It is easy to set up on any customer-grade hardware running
Ubuntu (ApacheMySQLPHP, 2014) or any other variant of Linux.
3.2.2 PYTHON
Python is another example of an interpreted, dynamically typed scripting language. As opposed to PHP,
Python is a general-purpose language and has a wider range of uses. It was created by Guido Van
Rossum in 1991 (Rossum, 2009) and despite version 3.0 being released in 2008, Python 2.X is still
widely used and supported due to backwards compatibility issues. In fact, version 2.7 was released after
Python 3.0, in 2010 and new iterations of Python 2.7 continue to be released in parallel with Python 3.
According to Przemysław Piotrowski, "One of Python's greatest strengths is its extensive standard
library, which provides an out-of-the-box set of modules for most programming tasks (Python
programmers refer to it as the "batteries-included strategy")" (Piotrowski, 2006). This makes Python
extremely versatile as it incorporates a wide array of tools for string processing, internet protocols,
multimedia formats and operating system interfaces.
Python's syntax is influenced by the ABC programming language (Python Software Foundation), which
uses indentations instead of curly braces for denoting blocks of code. This enforces developers to
correctly indent their code, which in turn makes it more readable. Python also makes it easier to work
with collections of items, replacing what would normally be a function call, or a loop with a simple
keyword (Python Software Foundation).
3.2.3 DJANGO
There are a number of web frameworks for Python allowing users to build dynamic websites, like
Django8
. Django provides web developers with a full set of tools to create a working website. It also has
its own Object Relational Mapping system, built-in admin panel, template system, etc.
A very useful Django feature is Object Relational Mapping. ORM abstracts database layer from the
developer and allows them to operate on instances of objects instead of writing SQL queries manually.
8
https://www.djangoproject.com/
33. Timetabling System Page | 21
ORM objects are created by defining a Python class extending Model, and Django creates a database
table and a Manager (Data Access Object) for that object (Django Software Foundation, 2014). Consider
Figure 3.1 which shows Python representation of Institution class. Every field is defined as a field on the
actual Python class and is assigned field type as initial value. There is a number of available field types
which define not only what type of data is stored in a field, but also how to validate it. For instance, all
CharField, AutoSlugField, ImageField, URLField, and even Image fields are all of type TEXT (for
SQLite). But Django defines different behaviour for each of these field types; While CharField is a
regular TEXT field, AutoSlugField generates a read-only slug value based on given field, URLField is a
URL string which also validates that given string is a valid URL, and ImageField stores path to a file,
but also handles file upload and validates that uploaded file is an image. Figure 3.2 shows Table schema
for Model presented in Figure 3.1. The Schema is generated creates an SQLite database table, but
Django also supports other databases, like MySQL and PostgreSQL and SQL generated for either will
differ slightly from SQLite.
class Institution(Model):
name_short = CharField("Short name", max_length=12, unique=True)
name = CharField("Full name", max_length=64)
slug = AutoSlugField(populate_from='name_short', primary_key=True)
logo = ImageField(upload_to='logos')
public = BooleanField(default=True)
website = URLField(blank=True)
support_email = EmailField(blank=True)
def __unicode__(self):
return self.name
class Meta:
ordering = ['name']
FIGURE 3.1 DJANGO MODEL DECLARATION FOR INSTITUTION
CREATE TABLE institutions_institution
(
name_short TEXT NOT NULL,
name TEXT NOT NULL,
slug TEXT PRIMARY KEY NOT NULL,
logo TEXT NOT NULL,
public INTEGER NOT NULL,
website TEXT NOT NULL,
support_email TEXT NOT NULL
);
FIGURE 3.2 INSTITUTION TABLE GENERATED BY DJANGO FOR SQLITE
34. Timetabling System Page | 22
3.3 DATABASE
Database is a crucial part of the timetabling system. Since all data used in the system will be related to
one another a suitable Relational Database Management System needs to be selected. Three of the most
popular RDBM systems were considered: SQLite, MySQL and PostgreSQL.
3.3.1 SQLITE
This lightweight database is commonly used in mobile systems like Android or iOS. It has been written
in C and can be added to any project as a library enabling relational database capabilities without the
need for the separate database process which is a unique feature for a database system. SQLite requires
no installation or configuration and is ACID (Atomicity, Consistency, Isolation, Durability) compliant
which makes it a very reliable solution comparing to raw files (About SQLite).
Comparing to other DBMSs, SQLite does not scale as well. This file-bound database only allows one
process to lock the database file at a time; therefore it's not suitable for online systems in production. But
it is a good solution for development environment as it's easy to set up on any computer and can be
packaged with the other development tools.
3.3.2 MYSQL
This open source (General Public License) Database Management System is a popular choice in a web
development world. It was originally released in 1995 by MySQL AB, which was later acquired by Sun
Microsystems and later Oracle (Krill, 2009). A lot of popular PHP systems support MySQL, like
Joomla, Wordpress, phpBB and Drupal.
MySQL is a part of the abovementioned LAMP stack, which also comes with phpMyAdmin, the web
interface for managing MySQL database. It also comes with command line utilities, like mysql to query
the database, and mysqldump to dump database contents in order to perform a backup.
Despite being most popular, MySQL has its flaws, some of which have been addressed in the 5.6 release
(Kanaracus, 2011).
35. Timetabling System Page | 23
3.3.3 POSTGRESQL
PostgreSQL is a well-regarded RDBMS due to its reliability and compliancy with standards. It also
provides a set of advanced features, like table inheritance, spatial data (PostGIS), rules system (query
rewrite) and events system (The PostgreSQL Global Development Group). PostgreSQL also supports a
number of programming languages in stored procedures, including Java and Python.
There is a number of utilities available for accessing and managing PostgreSQL databases. Similarly to
MySQL utilities, there is psql command line program for querying database, and pg_dump for backing
up database contents. There is also a web-based administration panel written in PHP: phpPgAmin9
.
3.4 FRONT-END
In order for the system to be responsive, some of the presentation logic has to be executed on the client-
side to prevent the network lag, and overloading the server. A number of front-end frameworks have
been considered to make the system more responsive.
3.4.1 JAVASCRIPT
This front-end scripting language is supported by most web browsers. JavaScript enables programmers
to write scripts that users can interact with while browsing the website. It was created in 1995 for the
Netscape web browser (Severance, 2012).
JavaScript is a very useful technology as it can take some load off the server by performing the logic on
user's machine. For instance, for the purpose of this project, all users can download full timetable and
filtering can be executed on the client side, without the need to do filtering on the server side and return
a different result for each user. Another advantage of this approach is, users would be able to change the
filtering of the timetable without the need to reload the whole page.
9
http://phppgadmin.sourceforge.net/doku.php
36. Timetabling System Page | 24
3.4.2 JQUERY
This popular JavaScript library10
simplifies scripting web pages. It is used by 60% of the top million
sites and it is estimated that 30% of websites in the entire internet uses it ( SimilarTech Ltd.).
The essence of jQuery is Document Object Model (DOM) manipulation. DOM is a tree structure
representing the layout of a HTML document. jQuery allows developers to select and manipulate
elements in DOM hierarchy using a simple selection language similar to that of Cascading Stylesheet
(CSS). This takes advantage of developers' prior knowledge of web technologies and makes transition to
jQuery straightforward. Apart from selecting and manipulating DOM elements, jQuery also allows for
easier separation of the JavaScript code from the HTML code. jQuery also handles any cross-platform
incompatibilities by providing a single interface for the developer and addressing browser
incompatibilities transparently.
3.4.3 ANGULARJS
Also known as "Angular"11
, this dynamic web application framework was developed by Google in 2009
and is still maintained under MIT license. As opposed to jQuery, which separates JavaScript from
HTML, Angular extends HTML and allows developer to use custom attributes to bind them with data
and events directly without having to write additional logic (Google).
Although AngularJS is designed mainly for Single Page Applications, the technology in it is also useful
for writing regular websites.
3.4.4 POLYMER
Another font-end framework developed by Google is Polymer12
. "Polymer returns to our roots. We think
the answer is not gobs of script, but rather to build more powerful elements. A set of powerful new
technologies called Web Components makes this possible" (Bidelman, 2014). This approach appears to
build upon how AngularJS works - instead of writing JavaScript code, developers can declare bindings
10
http://jquery.com/
11
https://angularjs.org/
12
https://www.polymer-project.org/
37. Timetabling System Page | 25
in the HTML code. But while in Angular the underlying code for directives is written in JavaScript,
Polymer allows developers to declare them using declarative HTML syntax (Mingoia, 2014). Polymer
comes with UI design elements that conform to Google's Material design language making it easy to
bootstrap a good looking and responsive app quickly.
However, due to it being relatively new, Polymer has not yet gained a traction in community support and
even though it's a great framework, it doesn't seem like a safe investment for now.
3.4.5 TWITTER BOOTSTRAP
Bootstrap13
is an open-source collection of CSS, JavaScript and HTML tools developed by Mark Otto
and Jacob Thornton at Twitter (Otto, 2012).
Bootstrap helps both designers and developers to quickly build a good looking and functional website. It
comes with a number of components that can be easily included in any simple web page, like navbar,
lists, dropdowns, tabbed navigation, dialogs, responsive grids, etc. This is particularly useful for
developers who don't have access to a designer and need to focus on business logic of the application,
but also want a pleasant looking app.
As of version 3, bootstrap is "mobile-first", meaning that the focus was put on the framework to scale its
component layout based on available screen real estate. This is particularly visible on the nav-bar which
shows all items on a desktop browser, but on mobile versions there is only the title and a menu button
where all hidden items reside. It also enables developers to implement their own scalable layouts using
just CSS (Cessa, 2013).
3.5 CONTINUOUS INTEGRATION
Continuous integration (CI) is a practice of merging parts of a multi-module applications and testing it
as a whole after each change.
13
http://getbootstrap.com/
38. Timetabling System Page | 26
This practice is useful for detecting issues early, so the developer can resolve issues as soon as they
surface (Fowler, 2006). Originally, CI was an activity practiced by developers themselves by running the
full suite of tests before committing their changes.
Building a project can be a complicated process; it can involve setting up a database, downloading
dependencies, building the code and running the tests - ideally with no preexisting condition in a clean
environment. As the project gets bigger, the process of continuous integration becomes longer and
requires automation. "A continuous integration server acts as a monitor to the repository. Every time a
commit against the repository finishes the server automatically checks out the sources onto the
integration machine, initiates a build, and notifies the committer of the result of the build. The committer
isn't done until she gets the notification - usually an email" (Fowler, 2006).
Even though this project will be developed by a sole developer, a CI solution is still beneficial. For once,
it will take away the burden of running tests often. As the project will get bigger, build times may
exceed acceptable time a developer is willing to wait before continuing the work, or only a subset of
tests will be ran by the developers to test the relevant modules, and CI can take perform full test of the
system in its own time. Another reason to use CI outside of development environment is, it will always
make a clean build from files checked into the repository. Files outside of version control may affect the
build, and a CI system will always make a build solely of the files in the VCS. This will detect common
mistakes like developer forgetting to check a file into the repository. As the development environment
(Windows) differs from production (Ubuntu) it could also be the case that testing in development
environment alone is not sufficient. In that case, having an extra integration environment, more closely
resembling production will be necessary in order to test code in a simulated production environment
before deployment.
3.5.1 JENKINS
This open-source CI software14
is a fork from Sun's Hudson written in Java. After a dispute over the
Hudson trademark, the open-source community renamed their version to Jenkins (Blewitt, 2011).
14
http://jenkins-ci.org/
39. Timetabling System Page | 27
Jenkins supports a number of VCSs and polls the remote repository in specified intervals to run the build
as soon as changes are detected. It is also possible to implement a post-commit hook in a version control
hosting software to notify the Jenkins server of the changes and trigger the build using a plug-in15
. This
CI software supports mainly Java, but can be extended by use of plugging16
and can execute arbitrary
batch/shell scripts.
3.5.2 TRAVIS CI
Another example of a continuous integration system is Travis CI17
. In contrast to Jenkins, Travis is a
hosted service targeted for public, open source project, but also available for private projects at a price.
Travis is easy to integrate with GitHub18
repositories. Travis users have an option to integrate their
Travis and GitHub accounts and easily import their repositories to the CI service. Such projects will
build automatically triggered by new commits being pushed. Resulting build status can be displayed in
the relevant project page on GitHub indicating if project in the current state builds successfully and
passes tests. Conveniently, it also builds and tests branches and relevant pull requests, so maintainers
know in advance if the proposed changes break the stability of the project.
Projects can be easily configured for Travis by placing a travis.yml file in the root of project directory19
.
The configuration file will usually specify the language of the project and steps to be executed as a part
of the Continuous Integration, like downloading dependencies, building, running tests, or even
deployment. This is different from Jenkins, where build is configured for each project in the CI panel.
All Travis builds run in a virtual machine created from snapshot before, and torn down after the build.
This is beneficial, because according to CI principles (Fowler, 2006), system state should not persist
between builds. This asserts that project builds in a clean environment with no external or residual
changes.
15
https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Hook+Plugin
16
https://wiki.jenkins-ci.org/display/JENKINS/Plugins
17
https://travis-ci.org
18
https://github.com/
19
http://docs.travis-ci.com/user/build-configuration/
40. Timetabling System Page | 28
FIGURE 3.3 TRAVIS CI SHOWS PROGRESS OF PUBLIC BUILDS
3.6 CONCLUSION
Given the aforementioned technologies, it has been decided that Django will be used for back-end due to
its superior model system, template engine and built in security against common threats.
For database, two systems were picked out for different purposes. In deployment the system should use
PostgreSQL database for its reliability and good opinion in the Django community. However, SQLite
will also be used for development environment, because it’s a more portable system and easier to set up,
which is an advantage in development environment.
After considering numerous front-end technologies, it has also been decided that multiple of them will
be used. First of all, Bootstrap will be employed for styling the website, and therefore jQuery will also
be used indirectly. AngularJS will be used for controlling client-side logic. Polymer has been decided
against, because at the moment it lacks traction in development communities and is not as popular as
other solutions – Bootstrap and AngularJS.
41. Timetabling System Page | 29
4 DESIGN
4.1 INTRODUCTION
This chapter will discuss in detail the design process leading up to the implementation of the system. It
will revisit the requirements of the application, address concerns associated with online systems, and
plan the implementation stage. Proposed database schema will also be designed in this part of the
documentation as it's a key part of the system.
4.2 USE CASES
The use case diagram demonstrates application of project requirements as outlined in chapter 1.3. As
demonstrated in Figure 4.1, there are five actors designed in the system.
The base actor is the Anonymous User. Anonymous User represents a user that visits the timetable
website without identifying themselves by logging in. Such person can view student (group) timetable
by specifying course and year of the class.
Teacher and Student users inherit the ability to view student timetables, but logged in students will also
have the ability to receive notifications on their smartphone about upcoming timetable events and
important notices. Teachers will be able to view teachers' timetables.
The institution administrator inherits teacher’s abilities to view student and teacher timetables, but they
will also have the ability to create and make modifications to the timetables and institution data, like the
name, campuses, rooms, etc. The System Admin (super user) will also have the ability to create and
manage institutions as well as manage user accounts.
42. Timetabling System Page | 30
FIGURE 4.1 USE CASE DIAGRAM OF THE SYSTEM
4.3 DESIGN CONCERNS
While developing an online system, there are a number of concerns that need to be taken into account
before implementation.
43. Timetabling System Page | 31
4.3.1 PERFORMANCE
Scalability is a vital part of an online system. This system in particular is targeted at supporting multiple
educational institutions and while over time the number of participating schools may increase, the
performance should stay at usable levels for all its users.
It is expected that there is going to be at least 20,000 users in an institution. In a system supporting
multiple institution, the number will be much greater. For simplicity it is expected that there is going to
be five institutions at certain point in the reasonable future. However, due to the nature of the system, it
is expected that a large portion of users will use the system at the same times. For instance, at the
beginning of the term, all users will need to view their new timetable. This will likely put a big strain on
the system. Similarly, it is expected that every day students will use the website to check upcoming
events and the system should provide continuous service in a reliable manner, because it will be relied
on by students and teachers.
There is a number of techniques that can be applied in order to handle web traffic at peak times
(Robenolt, 2013). An important one is caching. There are multiple levels of cache in Django; there is a
low level database cache and view cache. But outside of the Django applications, a higher level of cache
is required to handle repeated HTTP requests. Varnish20
is that layer of cache that handles requests
before they reach the Django application. On top of this, data should be cached at users' endpoints when
possible. For instance, a mobile app needn't download the timetable each time it's open. It can store a
local copy and update periodically, or whenever a notification is received that timetable has changed.
4.3.2 SECURITY
Security is a very important aspect to consider when designing an online system. Nowadays a lot of
websites face various types of attacks from identity theft to denial of service. But security is more than
counteracting malicious activity. Security consists of three key parts: Confidentiality, Integrity and
Availability (Perrin, 2008). Any online system will likely contain some sort of confidential information.
The timetabling system may contain some personal student and teacher information which should be
protected from third parties.
20
https://www.varnish-cache.org/
44. Timetabling System Page | 32
Due to the nature of the system, where there is data for multiple institutions, it is important to take into
account user permissions and differentiate users belonging to different institutions. Also, institution
admins while given full access rights to manage institution and timetables, should be limited to only
items related to the same institution. Availability of the system will be partially secured by performance
discussed in chapter 4.3.1. Additionally, in order to assure system availability, there should be
precautionary measures in place, like regular backups.
There are a number of common attack types that target web services. Some of them are Cross Site
Scripting (XSS), Cross Site Request Forgery (CSRF), SQL Injection, Denial of Service (DoS). Django
covers some of these common attacks by implementing security features at its code.
XSS attacks are mitigated by sanitizing all output in going to the browser. This feature escapes all
special characters in potentially dangerous user content saved in database and displays it as plain text in
the browser.
CSRF is a form of attack where a specially prepared script can execute actions as logged in user in an
online service without their knowledge. Django counters this by requiring a CSRF token for every POST
request. This token is usually attached to a form if a user legitimately visits the page to submit the
action.
SQL injection is another common form of attack where the attacker prepares a special string which
when inserted into an SQL query, performs malicious actions. Django handles these attacks by
abstracting database requests from developer. Using Django’s model system, developer can be sure that
all input is properly sanitized. Of course, developers still have the option of writing raw queries, in
which case care must be taken to escape special characters in any input.
DoS is a common form of attach where the attacker sends overwhelming amount of requests to the
server making it too busy to serve other clients. Denial of Service attacks are difficult to counter, but can
be mitigated by implementing good load balancing and cache mechanism.
4.3.3 RESPONSIVE UI
Since students will be using the system on a number of different devices, it is important that the User
Interface (UI) scales well across these form factors. According to the survey carried out in chapter 2.2,
45. Timetabling System Page | 33
students use mainly smartphones and laptops in college. It is important to take advantage of screen real
estate of a laptop, but at the same time, display all relevant information on a mobile device.
This issue is addressed by Bootstrap as reviewed in chapter 3.4.5. Bootstrap 3 is a screen size conscious
framework that allows developer to easily develop responsive web pages that adapt to user’s platform.
The reader is referred to Figure 4.2 Timetable viewshowing full timetable being displayed on a large
desktop monitor. This view shows timetable for all days on the screen including time slots. Please note
that timetable for each day is displayed in a column, as opposed to the DIT timetable convention (row).
This is a conscious decision to make the table scale better, because the same timetable displayed on a
smaller device (Figure 4.3) shows only single day, and allows for natural vertical scrolling if all events
don’t fit on the screen. User can still view their timetable for a different day by selecting a tab above the
timetable. Also, please note that in this view day names as well as name of the institution in the
breadcrumb are automatically shortened to adapt text to a smaller screen.
FIGURE 4.2 TIMETABLE VIEW
46. Timetabling System Page | 34
FIGURE 4.3 TIMETABLE DISPLAYED ON A MOBILE DEVICE
4.4 TECHNICAL SYSTEM DESIGN
The system will implement an extended version of the common three-tier architecture. As demonstrated
in Figure 4.4 System architecture, the system will consist of the web server, which will be the focal point
of the system, the database, and a client mobile application, which will be built upon existing app. The
Content Management System (CMS) will allow institution administration to manage institution
resources (rooms, teachers, campuses, etc), and timetables. Students and teachers will be able to view
their timetables using the website. Super user will be able to manage all items in the database regardless
of Institution and provide support for its users. Super users will user Django's built in interface, while
47. Timetabling System Page | 35
institution admin will have access to a custom made administration panel limiting their access rights to a
single institution.
FIGURE 4.4 SYSTEM ARCHITECTURE
The existing android app21
will be upgraded to use the new system instead of connecting to DIT servers
directly. The current timetable parsing logic will be removed from the application and new system's
REST (Representational State Transfer) API will be used in its place. Timetable parsing logic will be re-
implemented in Python to run in the new system. This will improve the application in several ways:
the mobile application will download data quicker since the timetables will be already parsed by
the server
mobile application will use less power, because it will not have to perform parsing on
downloaded data
21
https://play.google.com/store/apps/details?id=com.mick88.dittimetable
48. Timetabling System Page | 36
less data will be used by the mobile app, because server API will output clean JSON data instead
of HTML. This is particularly important on metered networks like 3G.
there will be less strain on the DIT servers as all data will be cached in the new system
parsing logic can be updated on the server without the need for users to update the app
The existing mobile app will be also expanded with new functionality:
Android Wear support
taking attendance (teachers)
registering attendance (students)
notifying of changes in the timetable
receiving messages from the system
notifying of upcoming timetable events (lectures, labs, etc)
A wearable component will be added to the existing Android app that will allow students to receive
notifications directly on the smartwatch and check their timetables without the need to use the
smartphone. To notify users of changes in their timetable, a third party messaging service will be used -
Google Cloud Services.
Additionally, the system will communicate with outside sources in order to synchronize timetable with a
legacy system, e.g. DIT timetables. This will be accomplished by downloading timetables from existing
system in HTML format, parsing them into Python objects, and inserting or updating entries in the
database.
An API will be also exposed to the Android application and potential future applications for other
platforms and services. The API will use JavaScript Object Notation (JSON) to output data requested by
clients. Tastypie Django extension will be used to implement it in the server.
4.5 DATABASE DESIGN
The database is created in a form of Django models which represent database tables. The reader is
referred to Figure 9.8 of the appendix showing the ERD of the complete database.
49. Timetabling System Page | 37
The main model, Institution, represents educational institution which can be one of many in the system.
The institution table (institutions_institution) stores information like the name, short name (to be used
where space is scarce), logo, etc. The logo is stored as a path to an image file saved in the file system. In
case of institution, the primary key is a slugified version of the short name. For instance, Dublin Institute
of Technology's short name is DIT, which renders slug dit. Slugs consists of lower case characters and
hyphens.
Another important model, Timetable, contains data about a single timetable. Timetable is a collection of
events which recur in the same timeframe (e.g. semester). Timetable model contains start and end date,
as well as the description. Timetables, as well as Institutions can be un-published, making them not
visible on the main page. The reader is referred to Table 4.1 outlining name, purpose and corresponding
model name of each table in the database.
Model name Table name Purpose
Institution institutions_institution Represents educational institution, contains basic
information like name, shortened name, logo, e-
mail and website addresses
Course institutions_course Stores course details, like code, name and foreign
key to the institution
Group institutions_group Represents an instance of course for given year
(class)
SubGroup institution_subgroup Represents a group inside group
Campus institution_campus Represents campus or a building
Room institutions_room Represents a room on a campus
Teacher institutions_teacher Stores information about a teacher or lecturer
Module institutions_module Stores information about module, or subject, such
50. Timetabling System Page | 38
as code, name, short name and foreign key to the
institution.
Timetable timetables_timetable Stores information about timetable, e.g. semester
Event timetables_event Represents an event in a timetable
- timetables_event_groups Facilitates many to many relationship between
event and group
- timetables_event_sub_groups Facilitates many to many relationship between
event and subgroup
TimeDef timetables_timedef Stores definition for times in a timetable, used for
grouping timeslot objects
Timeslot timetables_timeslot Represents timeslot in a timetable day
TimetableUpdat
eLog
timetables_timetableupdatelog Keeps track of when each timetable was last
imported from an external system (e.g. DIT)
WeekRangeCac
heEntry
timetables_weekrangecacheent
ry
Stores week range entry for timetable importer
InstitutionUser users_institutionuser Represents a user in the system
Student users_student Contains student-specific information about users
who are students, such as student number and
group that they belong to
EventAttendanc
e
attendance_eventattendance Represents attendance for one instance of an event
StudentAttenda
nceEntry
attendance_studentattendancee
ntry
Represents a student's response to the attendance
request, whether they are present or not
51. Timetabling System Page | 39
TimetableClient
Device
notifications_timetableclientde
vice
Stores data about Google Cloud Messaging
device. Used for sending push notifications
Feedback CMS_feedback Stores user feedback for site administrator
TABLE 4.1 DATABASE TABLES, THEIR CORRESPONDING MODELS AND PURPOSE
4.6 CONCLUSION
This chapter introduced the reader to the key parts of the system’s design. It presented the system’s use
cases, considered the important design concerns of online systems, like performance, security and
responsive UI. This chapter also walked the reader through the technical design of the system as well as
design of database schema.
52. Timetabling System Page | 40
5 IMPLEMENTATION
5.1 INTRODUCTION
This chapter will introduce the reader to the development environment used to develop the project, the
tools used and walk the reader through the steps taken to deploy the project to the server. It will also go
into details of implementation of each objective as listed in chapter 1.4 following the designs outlined in
chapter 4.
5.2 DEVELOPMENT ENVIRONMENT
As outlined in chapter 3.6, the project is developed in Python using the Django framework. The
development environment consists of the PyCharm 3.4 and 4.0 22
as the leading Integrated Development
Environment (IDE) for Python and Django, which comes with support for VCS (Version Control
Systems) and PIP (dependency management). The reader is referred to Figure 9.6 showing PyCharm
GUI. The VCS used to control source code of the application is Git 1.9.4 23
and repository hosted at
GitHub24
. The development platform is Windows 8 .1 PC and a Windows 8.1 laptop.
Project dependencies are managed using PIP 25
and requirements.txt inside a python virtual
environment26
. PIP assures that packages listed in requirements.txt are available in the development
environment at the exact version specified, and virtualenv separates development environments between
projects. Bower27
is used for front-end dependencies such as JavaScript and CSS tools.
Because of using multiple computers for development environments, it was necessary to automate the
process of setting up the database by creating a shell script setupdatabase.sh. The script creates the
database and user, then invokes migrate command in Django, which creates the required tables in the
database based on the defined models. Next the script creates super user and invokes load_data.py
22
https://www.jetbrains.com/pycharm/
23
http://git-scm.com/
24
https://github.com/
25
https://pypi.python.org/pypi/pip
26
http://virtualenv.readthedocs.org/en/latest/virtualenv.html
27
http://bower.io/
53. Timetabling System Page | 41
python script which populates the database with initial data, like institution and timetable objects. The
script is invoked each time there is a change in Django models in order to propagate those changes to
database. Database can be also updated without losing data by creating migrations.
#!/bin/bash
psql -U postgres -h localhost -c "CREATE USER timetables WITH PASSWORD
'password';"
psql -U postgres -h localhost -c "ALTER USER timetables CREATEDB;"
dropdb -U postgres -h 127.0.0.1 timetables
createdb -U postgres -h 127.0.0.1 -O timetables timetables
password="password"
superuser_email=michaldabski@gmail.com
rm CMS/static/img/ -r
python manage.py migrate
python manage.py createsuperuser --email=$superuser_email --noinput
echo "Created superuser $superuser_email with password $password"
python manage.py runscript load_data
python manage.py set_fake_passwords --password=$password
FIGURE 5.1 SETUPDATABASE.SH SCRIPT RESPONSIBLE FOR CREATING AND POPULATING
DATABASE FOR DEVELOPMENT ENVIRONMENT
5.3 DEVELOPMENT PHASES
5.3.1 DATABASE MODELS AND MANAGEMENT
The implementation of the system started with creating Django models as demonstrated in chapter 3.2.3.
After creating models, ./manage.py migrate command was executed for Django to generate the database
based on the models. Additionally, load_data.py script was created to populate the database with initial
data.
Initial management panel was created by enabling Django built-in admin panel. The admin panel can be
configured per model basis by extending ModelAdmin class. As demonstrated in Figure 5.2, developer
can define a list of fields displayed in the “list” view by adding a list_display field. Some fields can be
made searchable in the admin panel by creating a search_fields list. The customized admin class can be
registered with the admin app by invoking admin.site.register() with name of the model and the admin
class as parameters. The reader is referred to Figure 9.7 of the appendix showing an example of Django
admin panel displaying a list of Institution object in a list as well as a search box at the top.
54. Timetabling System Page | 42
class InstitutionAdmin(ModelAdmin):
list_display = ['name_short', 'name']
search_fields = ['name', 'name_short']
admin.site.register(Institution, InstitutionAdmin)
FIGURE 5.2 DJANGO ADMIN CONFIGURATION CLASS
5.3.2 HOME PAGE AND STYLING
The Home Page is the main page that students will visit in order to access their timetables. It will present
the user with a grid of institutions from which they will select their school. The reader is referred to
Figure 5.3.
FIGURE 5.3 HOME PAGE OF THE SYSTEM SHOWS PARTICIPATING INSTITUTIONS
55. Timetabling System Page | 43
5.3.3 COURSE SELECTION PAGE
Course selection page, is an interactive page where user will be able to select their course and will be
presented with a list of groups in that course. This page is implemented using AngularJS to fetch
available groups when user selects their course. This saves user from reloading the page as the
AngularJS script will efficiently fetch only relevant information.
FIGURE 5.4 COURSE SELECTION PAGE
After importing full suite of courses from DIT servers, it became apparent that this design does not scale
correctly as it requires user to manually look up their course in a list of 300 and then scroll to the top and
select their year. Following testing and user feedback it was concluded that a different implementation
was required, thus Bootstrap Multiselect plugin28
was used. The new solution has only one list of groups
which combines both course codes and years. It allows user to enter their course code or part of it, and
select the item from the filtered list.
28
http://davidstutz.github.io/bootstrap-multiselect/
56. Timetabling System Page | 44
FIGURE 5.5 REVISITED IMPLEMENTATION OF GROUP SELECTION
5.3.4 TIMETABLE VIEW
The timetable view is the main page in the system. It presents user with their timetable. The reader is
referred to Figure 4.2. The system allows users to access the timetable by URL without the need to log
in. This enables students to bookmark their timetables as well as share the URL with colleagues.
The timetable is implemented as a Django class view. This allows developer to create multiple
implementations of the view in different contexts and reduce code duplication. The Base timetable view
implements the framework for selecting the timetable, create base queryset for events, render the
timetable as well as export the timetable as a PDF document as described in 5.3.10. The implementing
classes only needs to modify event queryset to only select events relevant to selected timetable type.
Implementing classes can also add other functionalities. For instance, the teacher timetable adds login
requirement and redirects to login page when an unauthorized user tries to view the timetable.
When timetable page accessed with a mobile device, such as smartphone, the page will show timetable
only for current day and allow user to change the day by selecting a different tab. The selected tab is
57. Timetabling System Page | 45
persisted added to the URL, which allows it to persist between page reloads. This is achieved by using
Bootstrap selective classes visible-lg to make certain days only visible on large screen. Bootstrap will
also display shorter variant of the institution name and day names if the screen is very small. AngularJS
has been used to handle clicks on the tabs and switch current day. All of the responsive logic in the
timetable page is implemented using front-end tools, meaning that if screen size, or browser window
size change, the page will dynamically adapt without the need to refresh the page.
5.3.5 USER TYPES AND LOGIN
As outlined in chapter 4.2, there are five actors taking part in the system, four of which are authenticated
types of user: Teacher, Student, Institution Admin, and System Admin (superuser). Each of these users
will have a authorization to different parts of the system; the Students will be able to see the public class
timetables, and configure their own profile (set their course and year), while Teachers will have access
to teacher timetables, and Institution Admins will have access to the institution management panel where
they can modify institution, timetable and user details. The System Admin will have access to the
generic Django admin, where they have access to all objects in the system.
The user class in this system extends Django's AbstractBaseUser, and is called Institution user. This
implies that each user will have a foreign key relationship to the relevant user, except for the System
Admin. The users are identified by their e-mail address and password. The field is_staff determines
whether the user has access to the institution management panel. User is determined to be a Teacher or a
student if there exist a Teacher, or Student object with one to one relationship to the user respectively.
5.3.6 INSTITUTION ADMIN PANEL
Facilitating of institution management is one of the most tedious tasks. Management should be able to
modify all institution data and at the same time separated from other institution. Each page of institution
management page needs to be secure and well tested. The source code for the management panel is
separated from the rest of the project by placing it in manage app and has its own css and javascript
files.
58. Timetabling System Page | 46
Figure 2.1 shows layout of the main page in the Institution management page. The management pages
have been implemented by using Django's generic views29
. The page has been divided into sections,
each responsible for different types.
The first section presents main details of the institution such as the name, abbreviated name, website
address, and support e-mail address. A Public tag is also displayed under the main information
indicating the institution is publicly visible on the home page and students can view its timetables.
Institution logo is also displayed on the right-hand side. Any of this information can be changed by
clicking Edit in the top-right of the panel. Reader is referred to Figure 9.9 of the Appendix showing the
user interface for modifying Institution details.
The second section displays a grid of campuses in a form of image and campus name. The manager can
also add a new campus by clicking New Campus in the top-right corner of the panel, or click an existing
campus to modify its name, short name, image, or to delete it. Rooms can also be managed within the
campus page. Reader is referred to Figure 9.10 of the Appendix showing user interface for managing
campus and rooms.
The Resources section provides links to manage Institution's resources, like timetables, teachers,
modules, courses, and groups. Each of these items typically brings user to a list view allowing the user
to add and modify the items as well as related items.
The timetables link brings user to the summary of timetables with their basic information, such as
description, start/end dates, importer and tags indicating if the timetable is made public and if it's
configured to synchronize with an outside source.
29
https://docs.djangoproject.com/en/1.7/topics/class-based-views/generic-display/
5.3.6.1 INSTITUTION MANAGEMENT
5.3.6.2 CAMPUS MANAGEMENT
5.3.6.3 OTHER RESOURCES
59. Timetabling System Page | 47
When a timetable is selected, the user can modify the timetable's properties as well as manage the events
within it as demonstrated in Figure 9.11 of the appendix. The timetable management page allows the
user to filter the events by group, by teacher or both as well as add more timetable events.
FIGURE 5.6 INSTITUTION ADMIN PANEL
60. Timetabling System Page | 48
5.3.7 TIMETABLE SYNCHRONIZATION WITH DIT
Synchronizing timetables is a complex problem which has been broken into the following components:
Handler, Importer and Parser. Each of these components plays an important role in the process of
synchronizing the timetable with an outside source. Institution administrator can select timetable
importer on per-timetable basis in the timetable management panel. The structure of the timetable
synchronization process is demonstrated in Figure 5.7.
FIGURE 5.7 FLOW OF DATA IN SYNCHRONIZATION LOGIC
TimetableHandler is the top level class responsible for synchronizing timetable. It takes an Importer
instance in the constructor parameter and decides whether timetable should be updated by checking last
entry in the update log. By default it is configured to allow update only once per 24 hours. When reading
5.3.7.1 TIMETABLE HANDLER
61. Timetabling System Page | 49
from update log, the handler also reads hash of the last imported timetable and passes that into the
importer to avoid parsing the timetable if it has not changed.
The timetable handler in itself is only responsible for synchronizing the local timetable with DIT
timetables on a remote server. It does not serve timetables in local database. This way it is an optional
extra for components that display timetable. Such components select the timetable events directly from
the database, but before they do so, a signal30
is sent which triggers timetable handler to check that the
timetable is up to date, and update if needed. The reader is referred to Figure Figure 5.8 showing the
relevant flow chart.
The handler updates group timetable by deleting all group's related events before calling importer to
import new set of events. If group is associated with events that have more groups, the event is not
deleted, by the group is removed from that event. In the event that the group still participates in the event
after the update, the parser logic will add the group to the same event rather than creating a new instance
of the same event.
The logic performed in the Handler as well as the wrapped importer and parser class are encapsulated in
an atomic database transaction that will roll back any changes in case of a failure. After the timetable
update operation is successful, the handler creates a log entry with the hash of newly downloaded
timetable and commits the transaction.
30
https://docs.djangoproject.com/en/1.7/topics/signals/
62. Timetabling System Page | 50
FIGURE 5.8 FLOWCHART DEMONSTRATES THE LOGIC BEHIND TIMETABLE
SYNCHRONIZATION
The TimetableImporter is an abstract class defining the interface for timetable importers. It defines
methods to fetch timetable, first week of the timetable, and week structure. An implementation of this
class should connect to external endpoints in order to fetch data and return it in the import_timetable
method. The timetable importer is selected on per-timetable basis as each timetable instance can specify
dotted python path of the importer path which is evaluated using Django's import_string method31
.
CmisImporter class is the main implementation of TimetableImporter. It implements importing
timetable from the Dublin Institute of Technology timetabling service. The importer fetches both html
and grid representation of the timetable in order to get all the information required.
31
https://docs.djangoproject.com/en/1.7/ref/utils/#django.utils.module_loading.import_string
5.3.7.2 IMPORTER
